10 ms·

Troy Hunt is such a treasure. And for us web application developers, there is no excuse for not having protection against credential stuffing! While the best de

Troy Hunt is such a treasure. And for us web application developers, there is no excuse for not having protection against credential stuffing! While the best defense is likely two-factor [1], checking against Hunt's hashed password database is also very good and requires no extra work for users! I don't have anything to back this up, but my guess is that the vast majority of compromised user accounts comes from credential stuffing/password re-use. It's really surprising to me when I hear that huge companies don't do this check.[2] It's simple, easy, takes about a day to set up. If you're a young CTO or early-stage engineer working on a web app and have never been targeted with a credential stuffing attack, let me tell you: It's coming! It's just a matter of time before it's 1AM and your phone blows up; your site is getting hammered; you think it's DDOS, but then realize most of the hits are on your login page, then realize that and then realize with a horrible feeling that some % of those hits are getting through the login page. You'll be up all night dealing with it, and then you have to make breach notifications, and that really sucks. Troy Hunt's free database will save you that heartache (probably). Just do it. 1. https://cheatsheetseries.owasp.org/cheatsheets/Credential_Stuffing_Prevention_Cheat_Sheet.html https://cheatsheetseries.owasp.org/cheatsheets/Credential_St... 2. Like 23andMe. https://news.ycombinator.com/item?id=37794379 https://news.ycombinator.com/item?id=37794379

LeifCarrotson 3y ago
> ... and then realize with a horrible feeling that some % of those hits are getting through the login page. The alternative is the exact same scenario, except that the percentage is several orders of magnitude lower, right? The small subset of your users that explicitly opted-out of 2-factor authentication (if you allow that) and who try to choose "Password1!" with a second exclamation point when your site said "Error, your password has seen 83,000 times in password dumps, please use a unique password" will still get hacked. Or is your expectation that no one will attack every user on your webapp with a credential stuffing attempt if they see that the probability of success is 0.001% instead of 1%?
- mulmen 3y ago
  The bad feeling comes from knowing you could have reasonably done something to mitigate the harm. Don't let perfect be the enemy of good. Remember that "identity theft" is marketing fluff. In a credential stuffing attack your business is the victim of fraud.
- adameasterling 3y ago
  Yes, same scenario, but far fewer logins are successful. 3 orders of magnitude sounds right, but I don't know precise numbers. (Can others shed light?) Three orders of magnitude is a lot!
- cedilla 3y ago
  Wait, a thousand fold decrease is not worth it? Your numbers literally turns a scenario where 200,000 accounts are hacked into one where 200 are exposed. Or one where 30 hacked accounts turn into 0 hacked accounts. There is a point where a difference in quantity becomes a difference in quality. I far prefer the latter scenarios.
  - cqqxo4zV46cp 3y ago
    Anybody (like GP) that doesn’t understand that this is entirely the nature of security work, should not be making any material decisions about security. The number of times I’ve seen DEVELOPERS neglect to implement materially useful security measures because “they’re not technically perfect!” Is astounding.
    - marcus0x62 3y ago
      The number of times I’ve seen purported security practitioners dismiss materially useful security measures because of some theoretical attack that nobody has ever seen in the wild in recorded history outside of stunt-hacking at Defcon is…probably higher
rockskon 3y ago
About a decade back, I was at an event that had an FBI employee presenting. During his presentation, he had mentioned a story of a sys admin who had been arrested for taking a hashed PW database in his company, comparing the hashes against known compromised one's (perhaps from haveibeenpwned?), and forced a password reset for everyone who had reused a password that had separately been compromised and sent an email to each employee explaining this. One of the employees was apoplectic at the actions of the sys admin and had accused him of violating her privacy by doing this. While I do not recall which party initiated legal action against the sys admin that led to his arrest (i.e. the employee or the company), the bottom line of the story was that the FBI employee (and, by extention, whichever judge was involved in adjudication the case) considered the act of a sys admin accessing password hashes placed under his care to be a criminal breach of privacy regardless of his intent being to improve his company's security against password stuffing attacks. Assuming the FBI employee didn't just make the whole thing up (which I have no reason to believe - there are a lot of tech-stupid judges and, especially a decade ago, tech-stupid FBI employees), it might be prudent to pass this by your legal team before checking for password hashes for your employees being in haveibeenpwned.
- incahoots 3y ago
  Well this unlocked a new fear I didn't know I needed to have. I suppose this is the massive drawback to allowing dinosaurs to spearhead policy and govern laws.
  - rockskon 3y ago
    For what it's worth, the average tech-smarts in the legal realm and within the FBI are significantly improved compared to 8 years ago. This is just from my personal observation. That said, there are still tremendous gaps yet to be bridged with the understanding of many procecutors and lawyers as well as weird applications of the law that aren't intuitive to people whose life is technology. For example (and I caveat this with IANAL): Did you know the physical medium you get Internet to your house determines what laws and processes the government can use to monitor your Internet traffic?
KolmogorovComp 3y ago
> ... and then realize with a horrible feeling that some % of those hits are getting through the login page. (Non sarcastic), why would you feel bad for users using 1234 as their passwords? Unless your website is aimed at vulnerable people, I consider this to be their responsibility. As other comments have said these users will probably go the easiest route (1234websitename) to fix the error. Any restriction you put on your password field reduces entropy, and safety for everyone (even if marginally so).
- cqqxo4zV46cp 3y ago
  Because anyone that has ever been responsible for anything knows that there’s a difference between something being your fault and something being your problem. Breach notification etc legislation in some jurisdictions will also require that you report successful widespread credential stuffing. Even AWS with their “shared responsibility model” works with GitHub etc to ensure that programmatic access credentials aren’t accidentally exposed via public repositories. This isn’t credential stuffing, but it’s a blindingly accurate demonstration of the fact that drawing a line in the sand and saying “users, work it out from here!” and attempting to wash your hands of the situation is nothing more than the ill-informed pipe dream of someone that’s never had to deal with this stuff in reality.
- CoffeeOnWrite 3y ago
  Have you ever operated an online business? Poor password choice is practically harmful to business. Marginal reduction of entropy by blocking breached passwords, what's the practical harm from that? 1234websitename is objectively better than 1234. I'll go with NIST on this one (yes, and have a minimum length too): > When processing requests to establish and change memorized secrets, verifiers SHALL compare the prospective secrets against a list that contains values known to be commonly-used, expected, or compromised... If the chosen secret is found in the list, the CSP or verifier SHALL advise the subscriber that they need to select a different secret, SHALL provide the reason for rejection, and SHALL require the subscriber to choose a different value. https://pages.nist.gov/800-63-3/sp800-63b.html#memsecret https://pages.nist.gov/800-63-3/sp800-63b.html#memsecret
santiagobasulto 3y ago
Sorry, I don't understand the procedure. If the database contains hashed passwords (I haven't seen or download the database), how can you know you're using the same salt and method that the one in the datbase? For example, let's say Tumblr was hacked and with it my password `hunter2`. Tumbler used some naive HMAC-MD5 method with a salt, but my site uses argon2 with (obviously) a different salt. Even though my password is the same (`hunter2`) the resulting hashed passwords will be different. How is this any effective preventing credential stuffing?
- adameasterling 3y ago
  One can only implement a HIBP check when one has access to the user's unhashed password. So, at login, registration, and password reset.
  - santiagobasulto 3y ago
    Yes, exactly, so that's why I was asking, you mentioned the database was of hashed passwords. The database then contains the source passwords? And you're preventing the user from using one of those passwords? Sorry, I still don't understand the procedure you mentioned and I'm genuinely curious.
    - adameasterling 3y ago
      Oh, I see the issue. The HIBP database is SHA-1 hashed with no salt. It was created from unhashed passwords. You can't download the unhashed version (you could of course compute it, if you really wanted to; but there's no need). So, the procedure you need to implement is, on login/registration/pw reset, you SHA-1 hash the user's unhashed password and do a indexed lookup on your copy of HIBP's database. Or if you don't want to maintain that copy, you can use HIBP's API to do something similar.
      - santiagobasulto 3y ago
        Ah! Thanks a lot, it now makes sense. So at some point HIBP has the unhashed passwords, they obviously don’t make those public, good trick. How do you handle this from a UX perspective? Just tell the user that password is “not strong enough”?
yashap 3y ago
Besides 2FA, rate limiting your login endpoint (both by IP address and username) is a much more robust protection against this attack. Especially if you include temporary bans (e.g. “20 failed login attempts with the same IP, and/or same username, in the past minute = 15 minute ban for that IP and/or username”). A lot of API gateways, K8s ingresses, etc. make this dead simple, and if not it’s also super easy to add with a few lines of code and something like Redis to store counts of recent login attempts. I do think checking against the HIBP DB is a good call too, but it doesn’t stop this attack overly well, rate limiting is a much better way to stop it.
- aaronharnly 3y ago
  Rate limiting definitely helps against credential stuffing in the form of trying a bunch of common passwords against random accounts. But there's also "stuffing" with known breached username+password combinations – in which case it still helps, but I don't think as much? In the latter the attack is much more likely to succeed and there's a much smaller number of values being attempted, so the threshold of detection + blocking would have to be much lower...
  - themoonisachees 3y ago
    The threshold is lower but in reality it still makes considerably more login attempts, many of them failed, than a normal client ever would. Credential stuffing attacks don't really limit themselves to a single account, even if it worked.
  - yashap 3y ago
    Yeah, I do think it's worth doing both :) As well as at least making 2FA an option for your users - 2FA is the ultimate defence to most of these problems, but depending on the company/use case, not everyone is willing to make it mandatory, it does tend to be a lot more annoying to users. Things like failed login rate limits, minimum password length/complexity, and banning known breached logins is less intrusive to the user, and still pretty good defence when combined, though not as good as 2FA.
solatic 3y ago
> If you're a young CTO or early-stage engineer working on a web app If you're working on a greenfield login/auth, please don't accept and store passwords in a database! Setup social OAuth, SSO, or magic link emails and make it someone else's problem.
- g_p 3y ago
  If you do go down this route though, be sure to read up on what you're deploying, and understand what your libraries are doing (and more importantly, not doing). You don't want to end up with a naive implementation of OAuth2 (like some big names had recently) which fails to check the audience parameter, and therefore lets anyone other service using the same SSO gain access to your users' accounts. Recent HN post on this - https://news.ycombinator.com/item?id=38009291 https://news.ycombinator.com/item?id=38009291
  - solatic 3y ago
    I agree, and thanks for pointing that out, but between the two security failures, I'd rather have an incorrect OAuth2 implementation, which can be quickly fixed with no impact on existing customers, than credential stuffing, where I need to email customers apologizing for why I needed to reset their passwords.

LeifCarrotson 3y ago

> ... and then realize with a horrible feeling that some % of those hits are getting through the login page. The alternative is the exact same scenario, except that the percentage is several orders of magnitude lower, right? The small subset of your users that explicitly opted-out of 2-factor authentication (if you allow that) and who try to choose "Password1!" with a second exclamation point when your site said "Error, your password has seen 83,000 times in password dumps, please use a unique password" will still get hacked. Or is your expectation that no one will attack every user on your webapp with a credential stuffing attempt if they see that the probability of success is 0.001% instead of 1%?

mulmen 3y ago
The bad feeling comes from knowing you could have reasonably done something to mitigate the harm. Don't let perfect be the enemy of good. Remember that "identity theft" is marketing fluff. In a credential stuffing attack your business is the victim of fraud.
adameasterling 3y ago
Yes, same scenario, but far fewer logins are successful. 3 orders of magnitude sounds right, but I don't know precise numbers. (Can others shed light?) Three orders of magnitude is a lot!
cedilla 3y ago
Wait, a thousand fold decrease is not worth it? Your numbers literally turns a scenario where 200,000 accounts are hacked into one where 200 are exposed. Or one where 30 hacked accounts turn into 0 hacked accounts. There is a point where a difference in quantity becomes a difference in quality. I far prefer the latter scenarios.
- cqqxo4zV46cp 3y ago
  Anybody (like GP) that doesn’t understand that this is entirely the nature of security work, should not be making any material decisions about security. The number of times I’ve seen DEVELOPERS neglect to implement materially useful security measures because “they’re not technically perfect!” Is astounding.
  - marcus0x62 3y ago
    The number of times I’ve seen purported security practitioners dismiss materially useful security measures because of some theoretical attack that nobody has ever seen in the wild in recorded history outside of stunt-hacking at Defcon is…probably higher

rockskon 3y ago

About a decade back, I was at an event that had an FBI employee presenting. During his presentation, he had mentioned a story of a sys admin who had been arrested for taking a hashed PW database in his company, comparing the hashes against known compromised one's (perhaps from haveibeenpwned?), and forced a password reset for everyone who had reused a password that had separately been compromised and sent an email to each employee explaining this. One of the employees was apoplectic at the actions of the sys admin and had accused him of violating her privacy by doing this. While I do not recall which party initiated legal action against the sys admin that led to his arrest (i.e. the employee or the company), the bottom line of the story was that the FBI employee (and, by extention, whichever judge was involved in adjudication the case) considered the act of a sys admin accessing password hashes placed under his care to be a criminal breach of privacy regardless of his intent being to improve his company's security against password stuffing attacks. Assuming the FBI employee didn't just make the whole thing up (which I have no reason to believe - there are a lot of tech-stupid judges and, especially a decade ago, tech-stupid FBI employees), it might be prudent to pass this by your legal team before checking for password hashes for your employees being in haveibeenpwned.

incahoots 3y ago
Well this unlocked a new fear I didn't know I needed to have. I suppose this is the massive drawback to allowing dinosaurs to spearhead policy and govern laws.
- rockskon 3y ago
  For what it's worth, the average tech-smarts in the legal realm and within the FBI are significantly improved compared to 8 years ago. This is just from my personal observation. That said, there are still tremendous gaps yet to be bridged with the understanding of many procecutors and lawyers as well as weird applications of the law that aren't intuitive to people whose life is technology. For example (and I caveat this with IANAL): Did you know the physical medium you get Internet to your house determines what laws and processes the government can use to monitor your Internet traffic?

KolmogorovComp 3y ago

> ... and then realize with a horrible feeling that some % of those hits are getting through the login page. (Non sarcastic), why would you feel bad for users using 1234 as their passwords? Unless your website is aimed at vulnerable people, I consider this to be their responsibility. As other comments have said these users will probably go the easiest route (1234websitename) to fix the error. Any restriction you put on your password field reduces entropy, and safety for everyone (even if marginally so).

cqqxo4zV46cp 3y ago
Because anyone that has ever been responsible for anything knows that there’s a difference between something being your fault and something being your problem. Breach notification etc legislation in some jurisdictions will also require that you report successful widespread credential stuffing. Even AWS with their “shared responsibility model” works with GitHub etc to ensure that programmatic access credentials aren’t accidentally exposed via public repositories. This isn’t credential stuffing, but it’s a blindingly accurate demonstration of the fact that drawing a line in the sand and saying “users, work it out from here!” and attempting to wash your hands of the situation is nothing more than the ill-informed pipe dream of someone that’s never had to deal with this stuff in reality.
CoffeeOnWrite 3y ago
Have you ever operated an online business? Poor password choice is practically harmful to business. Marginal reduction of entropy by blocking breached passwords, what's the practical harm from that? 1234websitename is objectively better than 1234. I'll go with NIST on this one (yes, and have a minimum length too): > When processing requests to establish and change memorized secrets, verifiers SHALL compare the prospective secrets against a list that contains values known to be commonly-used, expected, or compromised... If the chosen secret is found in the list, the CSP or verifier SHALL advise the subscriber that they need to select a different secret, SHALL provide the reason for rejection, and SHALL require the subscriber to choose a different value. https://pages.nist.gov/800-63-3/sp800-63b.html#memsecret https://pages.nist.gov/800-63-3/sp800-63b.html#memsecret

santiagobasulto 3y ago

Sorry, I don't understand the procedure. If the database contains hashed passwords (I haven't seen or download the database), how can you know you're using the same salt and method that the one in the datbase? For example, let's say Tumblr was hacked and with it my password `hunter2`. Tumbler used some naive HMAC-MD5 method with a salt, but my site uses argon2 with (obviously) a different salt. Even though my password is the same (`hunter2`) the resulting hashed passwords will be different. How is this any effective preventing credential stuffing?

adameasterling 3y ago
One can only implement a HIBP check when one has access to the user's unhashed password. So, at login, registration, and password reset.
- santiagobasulto 3y ago
  Yes, exactly, so that's why I was asking, you mentioned the database was of hashed passwords. The database then contains the source passwords? And you're preventing the user from using one of those passwords? Sorry, I still don't understand the procedure you mentioned and I'm genuinely curious.
  - adameasterling 3y ago
    Oh, I see the issue. The HIBP database is SHA-1 hashed with no salt. It was created from unhashed passwords. You can't download the unhashed version (you could of course compute it, if you really wanted to; but there's no need). So, the procedure you need to implement is, on login/registration/pw reset, you SHA-1 hash the user's unhashed password and do a indexed lookup on your copy of HIBP's database. Or if you don't want to maintain that copy, you can use HIBP's API to do something similar.
    - santiagobasulto 3y ago
      Ah! Thanks a lot, it now makes sense. So at some point HIBP has the unhashed passwords, they obviously don’t make those public, good trick. How do you handle this from a UX perspective? Just tell the user that password is “not strong enough”?

yashap 3y ago

Besides 2FA, rate limiting your login endpoint (both by IP address and username) is a much more robust protection against this attack. Especially if you include temporary bans (e.g. “20 failed login attempts with the same IP, and/or same username, in the past minute = 15 minute ban for that IP and/or username”). A lot of API gateways, K8s ingresses, etc. make this dead simple, and if not it’s also super easy to add with a few lines of code and something like Redis to store counts of recent login attempts. I do think checking against the HIBP DB is a good call too, but it doesn’t stop this attack overly well, rate limiting is a much better way to stop it.

aaronharnly 3y ago
Rate limiting definitely helps against credential stuffing in the form of trying a bunch of common passwords against random accounts. But there's also "stuffing" with known breached username+password combinations – in which case it still helps, but I don't think as much? In the latter the attack is much more likely to succeed and there's a much smaller number of values being attempted, so the threshold of detection + blocking would have to be much lower...
- themoonisachees 3y ago
  The threshold is lower but in reality it still makes considerably more login attempts, many of them failed, than a normal client ever would. Credential stuffing attacks don't really limit themselves to a single account, even if it worked.
- yashap 3y ago
  Yeah, I do think it's worth doing both :) As well as at least making 2FA an option for your users - 2FA is the ultimate defence to most of these problems, but depending on the company/use case, not everyone is willing to make it mandatory, it does tend to be a lot more annoying to users. Things like failed login rate limits, minimum password length/complexity, and banning known breached logins is less intrusive to the user, and still pretty good defence when combined, though not as good as 2FA.

solatic 3y ago

> If you're a young CTO or early-stage engineer working on a web app If you're working on a greenfield login/auth, please don't accept and store passwords in a database! Setup social OAuth, SSO, or magic link emails and make it someone else's problem.

g_p 3y ago
If you do go down this route though, be sure to read up on what you're deploying, and understand what your libraries are doing (and more importantly, not doing). You don't want to end up with a naive implementation of OAuth2 (like some big names had recently) which fails to check the audience parameter, and therefore lets anyone other service using the same SSO gain access to your users' accounts. Recent HN post on this - https://news.ycombinator.com/item?id=38009291 https://news.ycombinator.com/item?id=38009291
- solatic 3y ago
  I agree, and thanks for pointing that out, but between the two security failures, I'd rather have an incorrect OAuth2 implementation, which can be quickly fixed with no impact on existing customers, than credential stuffing, where I need to email customers apologizing for why I needed to reset their passwords.