3 ms·

Also, a response to some of the mitigation’s suggested here: 1. Prevent people from reusing passwords from other websites/lists. Fail: you shouldn’t know if t

Also, a response to some of the mitigation’s suggested here: 1. Prevent people from reusing passwords from other websites/lists. Fail: you shouldn’t know if the pw is the same as any other pw. If you can tell, you are already doing it wrong. PW + random salt protects you against reused passwords. If your application is able to compare other passwords to the current password, not only did the othe site fuck up, but you did too. (re)Captcha: fuck you. Even if it’s after the second failed attempt. Fuck you. I hate you. You are implementing security theater, making everything worse for the user, and killing your conversation rate for everyone but spammers,who have this down pat. Pushing x numbers of rules, whether or not they are special characters or not. 8 vs. 10 doesn’t matter that much. Push passphrases instead. Multi-factor is sort-of okay, but the implementations are garbage and the user experience is awful. I’m not a security expert or a researcher. I’m a data engineer with a lot of web app experience. But most of the advice in this thread is total garbage. Web apps need to find a way to make the gold-standard of authentication accessible to users: per-device public/private key pairs. Until we do that well, we suck at life and our jobs compared to native apps. I include myself when I say that we have held ourselves to an incredibly low standard. OWASP is a pathetically low bar. Yet we often fail. It’s time to step up our game, people. And it’s on us to do it.

jjnoakes 9y ago
> PW + random salt protects you against reused passwords. That only protects you if every other site does it. If you salt your passwords and some other site which doesn't is compromised, you are hosed too if your users reused passwords. > If your application is able to compare other passwords to the current password, not only did the othe site fuck up, but you did too. Sorry, don't follow. How is it a mistake to compare a password your user is entering to a known blacklist of compromised passwords?
- 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 ago
    Comparing 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.

jjnoakes 9y ago

> PW + random salt protects you against reused passwords. That only protects you if every other site does it. If you salt your passwords and some other site which doesn't is compromised, you are hosed too if your users reused passwords. > If your application is able to compare other passwords to the current password, not only did the othe site fuck up, but you did too. Sorry, don't follow. How is it a mistake to compare a password your user is entering to a known blacklist of compromised passwords?

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 ago
  Comparing 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.