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.
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.
> 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
Server -> User : blinding factor
User -> Server: H(password || blinding factor)
Server: stores/checks what?
Server stores H(pw || bFixed)
Server sends bFixed, bOnce
Client sends H(H(pw || bFixed) || bOnce)
What I had in mind is this:
Server stores H(H(pw || bFixedPub) || bFixedPriv) , bFixedPub , bFixedPriv
Server sends bFixedPub
Client sends H(pw || bFixedPub)
(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.
So treat it like a password, salt it, do X rounds, and stores/checks result
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.
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
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.
> 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.
Isn't that what the rounds protects from?
If it's not, then it probably won't be implementing your protocol either!
I agree that the current methods could be massively improved.
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
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), 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
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.
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?
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-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
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