4 ms·
> 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
by homakov 9y ago
> 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-cryptocurrency-ff73dd65ecd9 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.
- zwily 9y agoI 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?
- homakov 9y agoRight 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.
- zwily 9y agoI 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.
- rocqua 9y agoI 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.