3 ms·

Sure, it does not help in strengthening this particular server's authentication mechanism. But it does serves as a proof for the user, that no matter however t

Sure, it does not help in strengthening this particular server's authentication mechanism. 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. And no matter how bad practice reusing a password is, people still do that, and I don't forsee a solution to that in the near future

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 ago
    Imagine 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.
deleted 7y ago
[deleted]
MattPalmer1086 7y ago
It only proves that the server isn't storing your original password (since it never receives it). Well designed servers using salts and good password hashing don't do this anyway (but there are plenty of bad ones out there). It doesn't prove that the server isn't just storing the derived password in plain text (which is all that is needed to log in to this server). And it still doesn't mean that the original password can't be recovered if the password db is compromised.
madacol 7y ago
@MattPalmer1086 Totally agree on the first 2 points > And it still doesn't mean that the original password can't be recovered if the password db is compromised. Why is that?
MattPalmer1086 7y ago
@madacol >> And it still doesn't mean that the original password can't be recovered if the password db is compromised. > Why is that? Because if I have the password db and the blinding value, I can just run a password cracker like hashcat over it to recover the original password with a reasonable probability. Modern password cracking rigs with multiple GPUs can try out billions of hashes a second. If you know the salt or blinding factor, you can often recover the password.
- madacol 7y ago
  > Modern password cracking rigs with multiple GPUs can try out billions of hashes a second. If you know the salt or blinding factor, you can often recover the password. Isn't that what the rounds protects from?
  - MattPalmer1086 7y ago
    You mean doing multiple rounds of hashing, like PBKDF2? There are some better algorithms than that now, but yeah, trying to slow down the computation required to crack the password is a useful defence.
    - madacol 7y ago
      Yeah, any way of increasing the cost factor, whether is PBKDF2 rounds, salt rounds in bcrypt, or just a pepper
  - MattPalmer1086 7y ago
    The thing is, if the server is already doing all that good stuff with your password, then you're already as well protected as you can be with the current methods. If it's not, then it probably won't be implementing your protocol either! I agree that the current methods could be massively improved.
    - madacol 7y ago
      In the supposed scenario that the server sucks, and it stores directly whatever you sent them, no rounds, no salt, nothing, what you are left with, is whatever protection you did on the client side, so I'm thinking doing the rounds client-side. Now that I'm thinking about it, I don't know how practical it is to do the rounds on a low-spec device like a cheap android

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 ago
  Imagine 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.

deleted 7y ago

[deleted]

MattPalmer1086 7y ago

It only proves that the server isn't storing your original password (since it never receives it). Well designed servers using salts and good password hashing don't do this anyway (but there are plenty of bad ones out there). It doesn't prove that the server isn't just storing the derived password in plain text (which is all that is needed to log in to this server). And it still doesn't mean that the original password can't be recovered if the password db is compromised.

madacol 7y ago

@MattPalmer1086 Totally agree on the first 2 points > And it still doesn't mean that the original password can't be recovered if the password db is compromised. Why is that?

MattPalmer1086 7y ago

@madacol >> And it still doesn't mean that the original password can't be recovered if the password db is compromised. > Why is that? Because if I have the password db and the blinding value, I can just run a password cracker like hashcat over it to recover the original password with a reasonable probability. Modern password cracking rigs with multiple GPUs can try out billions of hashes a second. If you know the salt or blinding factor, you can often recover the password.

madacol 7y ago
> Modern password cracking rigs with multiple GPUs can try out billions of hashes a second. If you know the salt or blinding factor, you can often recover the password. Isn't that what the rounds protects from?
- MattPalmer1086 7y ago
  You mean doing multiple rounds of hashing, like PBKDF2? There are some better algorithms than that now, but yeah, trying to slow down the computation required to crack the password is a useful defence.
  - madacol 7y ago
    Yeah, any way of increasing the cost factor, whether is PBKDF2 rounds, salt rounds in bcrypt, or just a pepper
- MattPalmer1086 7y ago
  The thing is, if the server is already doing all that good stuff with your password, then you're already as well protected as you can be with the current methods. If it's not, then it probably won't be implementing your protocol either! I agree that the current methods could be massively improved.
  - madacol 7y ago
    In the supposed scenario that the server sucks, and it stores directly whatever you sent them, no rounds, no salt, nothing, what you are left with, is whatever protection you did on the client side, so I'm thinking doing the rounds client-side. Now that I'm thinking about it, I don't know how practical it is to do the rounds on a low-spec device like a cheap android