3 ms·
To your second point, giving this information leaks too much about the user trying to create a password. I go to a site and try to register an account. The app
by ianamartin 9y ago
To your second point, giving this information leaks too much about the user trying to create a password.
I go to a site and try to register an account. The app says, “sorry, you can’t use that password because it’s been used with this username before and has been compromised.” Your attacker now knows that the user is in a compromised list.
You can’t do this without leaking information about the user.
If you compare to a global list instead of the user, then you’ve leaked the opposite information. That at least one user is on some list of compromised passwords.
You can’t do that without leaking information about at least one user.
And, as discussed, exponential fall-off doesn’t work in the world of distributed attacks.
That’s my response to point two in a nutshell. But I’ll add that the application layer should have no knowledge of the plain-text password to begin with. The password should be hashed on the client side before being sent to the application layer. Then salted and hashed and stored in the database.
The double hashing doesn’t get you anything in crypto terms as far as I know, but it means that if your application leaks or the network between the front and back end is MITMd, then you are leaking hashes and not plain text.
Of course, if the network between your front and back ends is compromised, you fucked up pretty bad anyway. But it adds at least a little effort for the attacker instead of allowing them to just grab username and password pairs in plain text.
I also salt + hash usernames in transit, so it’s not immediately obvious who is associated with what.
That gets me to your first point.
You are correct that doing all of this doesn’t protect any individual user from illicit access, and I should have been more clear about my concerns. If an individual user chooses to reuse passwords, their account can be compromised. You are 100% correct about that.
But in the case of a data breach, which is what I was thinking of in terms of “preotection”, it’s going to be really hard to compromise a collection of salted, hashed username/password combos.
In my opinion—again, I’m not a security expert, and I welcome criticisms such as yours—I don’t think we’re going to get people to stop reusing passwords. And I don’t think we’re going to get people to use multi-auth any time soon.
I think this is the best we can do until someone comes up with a way to get per-device key pairs to work in a friendly way.
Thanks for your thoughts and criticisms and questions.
- jjnoakes 9y agoComparing passwords to a list of compromised ones doesn't leak anything. Just ignore the user name. And hashing on the client in addition to the server doesn't save you from any mitm attacks.