|
|
|
|
|
by homakov
3306 days 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-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. |
|
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.