It's essentially the offline password manager idea with some kinks worked out.

The offline password doesn't use an encrypted database, but instead used a key-derivation function based on a master password and e.g. the service name to get deterministic passwords.

In the case of a password manager, there are issues with password requirements and service name reuse. Here, by switching to a signing protocol, those issues are mitigated. At the same time, because this isn't the password protocol, it forces users to use this app. Meanwhile, you can't force users to use a password manager, leading to horrible password reuse.

The big downside I see is the immediate compromise upon revealing your master password. In the case of a PW manager, your opponent needs to get to your database first. This might give you time to roll-over your passwords.

Another thing I don't see is key-revocation. What to do when you fear your master password is compromised? That might just be done by essentially the same as a password change though.

> Another thing I don't see is key-revocation

There's a button "Change SecureLogin" which essentially replaces old pubkey with new one. One would have to do it with all services they every used, and do it before the attacker. It could be automated though.

> The big downside I see is the immediate compromise upon revealing your master password

On this problem I wrote another blog post https://medium.com/@homakov/why-brainwallet-are-great-for-cr...

I believe having to worry about 1 thing is better than 2. It's losing (usability) > stealing (security) in this problem.

But otherwise you summed up everything properly, just what I was trying to say.

I personally still prefer a password vault stored in the cloud combined with a strong master password.

You can quite freely backup the password vault, because pure access to it isn't the end-all-be-all. It's essentially a second factor.

I'd also like to compare this to a simpler challenge-response based protocol. Have the shared secret be e.g. SS = scrypt(hmac(passwd, serviceID)), and the challenge be nonce, to which one should respond hmac(SS, nonce).

The biggest difference I see is the issue of leaking the shared secret. It doesn't leak anything about the passwd, but compromises access to the service. If your public key leaks, that still can't be used to authenticate you with the service. If I'm not mistaken, the shared secret approach has the advantage of better privacy.

I tried the "Change SecureLogin" flow, and it's not obvious to me how that works if I'm changing my master password. It lets me select a new profile from within the app, but won't that also change my email address?

Right now email is not changed, because it's not used as primary key, it's just a label like your fullname.

After you changed you can get into the same account using your 2nd profile only. Ignore the email: site owners are free to confirm it, but playground does not.

I did try to create a new profile with the same email address and it didn't let me, so it does appear to be treating it sort of like a primary key.

And if it's just a label, then maybe it should be advertised as such. I see what you're saying now, but that's not obvious from the app.

If this protocol got implemented widely, I think there would be some value in creating an alternative app that essentially combines this with a local password database. The app could automatically generate site-specific keypairs, and you would still only need to memorize your master password.

This combination would solve the problem of your master password being disclosed (your opponent still needs to get your database), while retaining the benefit of giving sites only your public key instead of a usable password.

The biggest problem here is multi-device support. Right now you can enter the same email + mpw on a different device and it just works. Adding a local secret means you must manually transfer that to any new device.

Seems like a good feature for people with stronger security requirements (eg, journalists), but not the average user.

The nice thing about the protocol is that the client-side app can actually be replaced. All you need is something that will manage the private key(s) and properly respond to the authentication challenge through the protocol handler.

So the average user can stick with the default app, while anyone who wants more security can opt for a vault-based version. This is similar to the current state of affairs with passwords, where users can opt to use password managers.

The important thing is that sites make the shift to a challenge-based protocol. Once that's done, there are lots of different ways of implementing the client-side app, all with different trade-offs. For example, you could replace the master password with a fingerprint.

No, it's decentralized as in "no central authority" not as in blockchain "many centers". It's a local client side app.