4 ms·
> But it does serves as a proof for the user, that no matter however the server is storing the password, it won't be linkable to other's server way of storing t
by blattimwind 7y ago
> But it does serves as a proof for the user, that no matter however the server is storing the password, it won't be linkable to other's server way of storing the password, in case of reusing passwords.
Oh but there is, you can just try logging in with it (either for real or by running the login protocol on a dump/leak).
- madacol 7y ago> Oh but there is, you can just try logging in with it (either for real or by running the login protocol on a dump/leak). Sure, but that leak must have been from the same source. Imagine you are a password-reuser, and you have registered with the same password in www.nottrustworthypage.com and www.yetanothernottrustworthypage.com If they are using a would-be browser's built-in password protocol (which doesn't exist today, but this is what I'm suggesting and I sketched it in this comment https://news.ycombinator.com/item?id=22257502 https://news.ycombinator.com/item?id=22257502), and you know that if they are not colliding by using the same salt, and as long as your password is strong so it's not easily crackable, then you can have a pretty high confidence that whichever gets leaked, is very unlikely to damage your others site security. Colliding salts require lots of efforts by the servers, and most of the damages produced by leaks, are because of lazyness
- blattimwind 7y agoImagine you are a password-reuser and you have registered with www.md5passwords.com and now BadPeople have cracked your password using a dictionary, BadPeople can now log into www.nottrustworthypage.com and www.yetanothernottrustworthypage.com. The problem of your site's password best practice handling is that it does nothing to harden your users against other site's bad password handling. Hence FIDO.