11 ms·

I think there should be a protocol in browsers where input password fields are hashed along with a blinding factor that comes from servers. I think that protoc

I think there should be a protocol in browsers where input password fields are hashed along with a blinding factor that comes from servers. I think that protocol would solve lots of basic problems in password security. But the most important thing is that it would serve as a proof that the server is not saving your password in plain text, because the plain text never gets there, only it's hash.

MattPalmer1086 7y ago
I can't see how this would work. Does the blinding factor change every time you log in? How does the server validate that your password is correct - what does it store? Server -> User : blinding factor User -> Server: H(password || blinding factor) Server: stores/checks what?
- madacol 7y ago
  Server should save the blinding factor along with the hash. (Maybe some sort of global blinding factor could work, and generate it deterministically?) Server saves more data, but has the benefit that the rounds is computed in the client, so server's hash verification could be faster. (EDIT: To reduce rounds in server is probably not a good idea) I'm no nearly an expert in this stuff, so take it with a kilogram of salt.
- usrusr 7y ago
  Server stores H(pw || bFixed) Server sends bFixed, bOnce Client sends H(H(pw || bFixed) || bOnce) The server can be trusted to not save the actual password if setup/change is already sending H(pw || bFixed) instead of the password itself. But then bFixed becomes public knowledge knowledge and a leaked H(pw || bFixed) would be enough to do a malicious login.
  - madacol 7y ago
    That's Interesting!. I didn't thought it that way What I had in mind is this: Server stores H(H(pw || bFixedPub) || bFixedPriv) , bFixedPub , bFixedPriv Server sends bFixedPub Client sends H(pw || bFixedPub) bFixedPub and bFixedPriv are unique per password.
  - deleted 7y ago
    [deleted]
- madacol 7y ago
  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
- zokier 7y ago
  Are you guys reinventing HTTP Digest auth here?
  - MattPalmer1086 7y ago
    Yep!
tialaramex 7y ago
There already are perfectly good algorithms for this stuff. What you want is an asymmetrical PAKE. The most notorious is SRP. Don't try to roll your own. But basically there's no appetite at this point to retrofit SRP or any PAKE to "normal" user login on the web. Avoid passwords altogether. If you must have passwords, have the very fewest possible (Buying more than one "single sign on" solution ought to be automatic grounds for firing the head of IT at a firm) and focus effort on getting rid of them not on trying to have better ones.
- deleted 7y ago
  [deleted]
- madacol 7y ago
  I explained more specifically what I am suggesting here. https://news.ycombinator.com/item?id=22257502 https://news.ycombinator.com/item?id=22257502 > Avoid passwords altogether... I understand your point of view and you are right, securing passwords is hard. I only see not-using-passwords feasible using hardware keys like yubikeys, which still might need a master password, but I don't see it becoming mainstream anytime soon

MattPalmer1086 7y ago

I can't see how this would work. Does the blinding factor change every time you log in? How does the server validate that your password is correct - what does it store? Server -> User : blinding factor User -> Server: H(password || blinding factor) Server: stores/checks what?

madacol 7y ago
Server should save the blinding factor along with the hash. (Maybe some sort of global blinding factor could work, and generate it deterministically?) Server saves more data, but has the benefit that the rounds is computed in the client, so server's hash verification could be faster. (EDIT: To reduce rounds in server is probably not a good idea) I'm no nearly an expert in this stuff, so take it with a kilogram of salt.
usrusr 7y ago
Server stores H(pw || bFixed) Server sends bFixed, bOnce Client sends H(H(pw || bFixed) || bOnce) The server can be trusted to not save the actual password if setup/change is already sending H(pw || bFixed) instead of the password itself. But then bFixed becomes public knowledge knowledge and a leaked H(pw || bFixed) would be enough to do a malicious login.
- madacol 7y ago
  That's Interesting!. I didn't thought it that way What I had in mind is this: Server stores H(H(pw || bFixedPub) || bFixedPriv) , bFixedPub , bFixedPriv Server sends bFixedPub Client sends H(pw || bFixedPub) bFixedPub and bFixedPriv are unique per password.
- deleted 7y ago
  [deleted]
madacol 7y ago
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
zokier 7y ago
Are you guys reinventing HTTP Digest auth here?
- MattPalmer1086 7y ago
  Yep!

tialaramex 7y ago

There already are perfectly good algorithms for this stuff. What you want is an asymmetrical PAKE. The most notorious is SRP. Don't try to roll your own. But basically there's no appetite at this point to retrofit SRP or any PAKE to "normal" user login on the web. Avoid passwords altogether. If you must have passwords, have the very fewest possible (Buying more than one "single sign on" solution ought to be automatic grounds for firing the head of IT at a firm) and focus effort on getting rid of them not on trying to have better ones.

deleted 7y ago
[deleted]
madacol 7y ago
I explained more specifically what I am suggesting here. https://news.ycombinator.com/item?id=22257502 https://news.ycombinator.com/item?id=22257502 > Avoid passwords altogether... I understand your point of view and you are right, securing passwords is hard. I only see not-using-passwords feasible using hardware keys like yubikeys, which still might need a master password, but I don't see it becoming mainstream anytime soon