I don't see any discussion about what this does besides decentralisation. Care to explain how it is securing through decentralisation? Is this some blockchain based solution?
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.
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.
Seems like a good feature for people with stronger security requirements (eg, journalists), but not the average user.
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.
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.
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.
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.
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.