3 ms·

From the point of view of the server, the password is H(password || blinding factor) So treat it like a password, salt it, do X rounds, and stores/checks resul

From the point of view of the server, the password is H(password || blinding factor) So treat it like a password, salt it, do X rounds, and stores/checks result

MattPalmer1086 7y ago
Indeed, from the point of view of everybody (except the user), the password is H(password || blinding factor). If I intercept H(password || blinding factor) and send it to the server (hashed with any other single use blinding factor), it will be accepted, even though I never knew the original password used to derive it. So, this doesn't really achieve the goal that the server never stores your password in plain text, since the "plain text" of the password is exactly H(password||blinding factor). It does mean the server may not know the original text you typed in to derive this password - but this is not needed to log in to the server.
- madacol 7y ago
  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
MattPalmer1086 7y ago
There are well worked out schemes which do achieve this e.g. Password Authenticated Key Exchange schemes (PAKE): https://blog.cryptographyengineering.com/2018/10/19/lets-talk-about-pake/ https://blog.cryptographyengineering.com/2018/10/19/lets-tal...
- madacol 7y ago
  I'm pretty sure there are lots more, that probably are even better But what I'm suggesting is that whatever it is, it should be integrated with the browser's, so that when I am typing my password in a special password-input-field (which doesn't exist today), no javascript is allowed to read it's plain text, until the user manually unlocks it and the page is able to read it's H(pw || bFixedPub) or whatever protocol is apropiate. That special password field, should appear outside the pageview, to prove that the page is not in control of it, or it's not allowed to phish it, only the browser has control, and when it's done, it sends to the page the resulting hash
  - MattPalmer1086 7y ago
    I do like the idea of password fields in browsers which can't be interrogated by javascript, a secure password protocol built in, and some way of making the authentication interface non spoofable.
- madacol 7y ago
  In the comments section of that link, I found interesting this thread that touches what I am suggesting: https://blog.cryptographyengineering.com/2018/10/19/lets-talk-about-pake/#comment-3888 https://blog.cryptographyengineering.com/2018/10/19/lets-tal... Which ends up with one of the parties writing this: https://palant.de/2018/10/25/should-your-next-web-based-login-form-avoid-sending-passwords-in-clear-text/ https://palant.de/2018/10/25/should-your-next-web-based-logi... The blog in the last link argues against the usefulness with the built-in browser implementation. The arguments are pretty useful, even though I disagree with he's conclusions. I think the fact that if a compromised server has to revert from the secure browser-built-in password form, to a "regular login form" in order to learn your password, then that's a win for me

From the point of view of the server, the password is H(password || blinding factor) So treat it like a password, salt it, do X rounds, and stores/checks result

MattPalmer1086 7y ago

Indeed, from the point of view of everybody (except the user), the password is H(password || blinding factor). If I intercept H(password || blinding factor) and send it to the server (hashed with any other single use blinding factor), it will be accepted, even though I never knew the original password used to derive it. So, this doesn't really achieve the goal that the server never stores your password in plain text, since the "plain text" of the password is exactly H(password||blinding factor). It does mean the server may not know the original text you typed in to derive this password - but this is not needed to log in to the server.

madacol 7y ago
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

MattPalmer1086 7y ago

There are well worked out schemes which do achieve this e.g. Password Authenticated Key Exchange schemes (PAKE): https://blog.cryptographyengineering.com/2018/10/19/lets-talk-about-pake/ https://blog.cryptographyengineering.com/2018/10/19/lets-tal...

madacol 7y ago
I'm pretty sure there are lots more, that probably are even better But what I'm suggesting is that whatever it is, it should be integrated with the browser's, so that when I am typing my password in a special password-input-field (which doesn't exist today), no javascript is allowed to read it's plain text, until the user manually unlocks it and the page is able to read it's H(pw || bFixedPub) or whatever protocol is apropiate. That special password field, should appear outside the pageview, to prove that the page is not in control of it, or it's not allowed to phish it, only the browser has control, and when it's done, it sends to the page the resulting hash
- MattPalmer1086 7y ago
  I do like the idea of password fields in browsers which can't be interrogated by javascript, a secure password protocol built in, and some way of making the authentication interface non spoofable.
madacol 7y ago
In the comments section of that link, I found interesting this thread that touches what I am suggesting: https://blog.cryptographyengineering.com/2018/10/19/lets-talk-about-pake/#comment-3888 https://blog.cryptographyengineering.com/2018/10/19/lets-tal... Which ends up with one of the parties writing this: https://palant.de/2018/10/25/should-your-next-web-based-login-form-avoid-sending-passwords-in-clear-text/ https://palant.de/2018/10/25/should-your-next-web-based-logi... The blog in the last link argues against the usefulness with the built-in browser implementation. The arguments are pretty useful, even though I disagree with he's conclusions. I think the fact that if a compromised server has to revert from the secure browser-built-in password form, to a "regular login form" in order to learn your password, then that's a win for me