4 ms·

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

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!

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!