Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Prevent users registering with passwords from data breaches

jordanhall.co.uk

Post reply on HN
Print view View original

11–20 of 129 posts

Re: Prevent users registering with passwords from data breaches

#11

Post by geofft »

throwawaymath wrote: post #8
bijection wrote: post #6

Earlier quoted context omitted.

Any known password is no longer a particularly strong one.

That doesn't make sense. If I publish a list of 20 trillion alphanumeric passwords, each of which is 20 characters long, your thesis is that no one should ever use any of those passwords again?

Yes, that is the correct conclusion. There are about 0.7 trillion trillion trillion alphanumeric passwords 20 characters long (62^20). Banning 20 trillion of them is a drop in the oceans, and nobody using a password generator is statistically likely to generate them within the expected lifetime of the universe, let alone of any given website. So, if you see one of those passwords, it is overwhelmingly likely that someone took a shortcut and used your list.

Re: Prevent users registering with passwords from data breaches

#12

Post by rmtech »

throwawaymath wrote: post #5

This is not a good idea, as implemented. You shouldn't disallow a user from using an otherwise strong password just because it's detected in a breach unless you can definitively see that it's already associated with their email address or username. The logical conclusion of a password checking system like this is that this password: ZBjHWJd$8XbJhY7LQvkmARBW)p7xgiDzDw}iMLLw can no longer be used by anyone, because I'v…

If the password actually has a lot of entropy but it appears in a breach then that's some fairly strong evidence that the user is reusing it.

Specifically if it appears n times in the HIBP database you should assign at least roughly 1/n probability that the user is reusing it.

So if you assign disutility -V to letting a user have a known username + password combo and utility U to letting a user sign up with a known password but unknown username, the utility is (n-1)/n×U - 1/n×V

Reasonable values of U and V for a given site will be different depending on the application, but for online banking -V would be maybe -20 and U might be negative as well. You wanna bank with a public password lol? For something like gmail or Facebook it would be the same story.

On the other hand if the password is quite weak then it's vulnerable to credential stuffing. If it appears, say, 10,000 times in the HIBP database then most likely it's as good as public whether or not the user account name is known.

Maybe there's a sweet spot around 50 instances where you can't really credential stuff it, and you also aren't that sure that it's a reuse.

In terms of usability you could tell the user to change it up a bit, add some words.

For example, r0bbiewilliams appears 5 times in the database. luvrobbiewilliams appears 0 times AND IS PROBABLY EASIER TO REMEMBER!

You can almost always get away from a breached password by adding a small amount of text.

Re: Prevent users registering with passwords from data breaches

#13

Post by throwawaymath »

rmtech wrote: post #12
throwawaymath wrote: post #5

This is not a good idea, as implemented. You shouldn't disallow a user from using an otherwise strong password just because it's detected in a breach unless you can definitively see that it's already associated with their email address or username. The logical conclusion of a password checking system like this is that this password: ZBjHWJd$8XbJhY7LQvkmARBW)p7xgiDzDw}iMLLw can no longer be used by anyone, because I'v…

If the password actually has a lot of entropy but it appears in a breach then that's some fairly strong evidence that the user is reusing it. Specifically if it appears n times in the HIBP database you should assign at least roughly 1/n probability that the user is reusing it. So if you assign disutility -V to letting a user have a known username + password combo and utility U to letting a user sign up with a known p…

> If the password actually has a lot of entropy but it appears in a breach then that's some fairly strong evidence that the user is reusing it.

I'm not talking about scenarios where you can associate the password with a specific user.

Re: Prevent users registering with passwords from data breaches

#14

Post by Buttons840 »

throwawaymath wrote: post #5

This is not a good idea, as implemented. You shouldn't disallow a user from using an otherwise strong password just because it's detected in a breach unless you can definitively see that it's already associated with their email address or username. The logical conclusion of a password checking system like this is that this password: ZBjHWJd$8XbJhY7LQvkmARBW)p7xgiDzDw}iMLLw can no longer be used by anyone, because I'v…

The odds of a user randomly selecting that password, rounded to 20 decimal places, is 0.

Re: Prevent users registering with passwords from data breaches

#15

Post by throwawaymath »

geofft wrote: post #11
throwawaymath wrote: post #8

Earlier quoted context omitted.

That doesn't make sense. If I publish a list of 20 trillion alphanumeric passwords, each of which is 20 characters long, your thesis is that no one should ever use any of those passwords again?

Yes, that is the correct conclusion. There are about 0.7 trillion trillion trillion alphanumeric passwords 20 characters long (62^20). Banning 20 trillion of them is a drop in the oceans, and nobody using a password generator is statistically likely to generate them within the expected lifetime of the universe, let alone of any given website. So, if you see one of those passwords, it is overwhelmingly likely that som…

No, it's not the correct conclusion. Virtually no passwords are safe under an offline brute force attempt if they haven't been protected by a robust key derivation function and a randomized salt. If the password has been protected like that, you not only need to try all 20 trillion of those hypothetical passwords; you also need to try them with the correct salt.

And this is aside from the fact that you won't even rip through those 20 trillion in an online brute force attempt. Eventually you are only constrained by computational resources. If the passwords are cryptographically secured, it's fine if any one of them is published on the internet if you cannot associate it with any given user. If they're not cryptographically secured, this won't meaningfully reduce your already poor security anyway.

Re: Prevent users registering with passwords from data breaches

#16

Post by geofft »

throwawaymath wrote: post #15
geofft wrote: post #11

Earlier quoted context omitted.

Yes, that is the correct conclusion. There are about 0.7 trillion trillion trillion alphanumeric passwords 20 characters long (62^20). Banning 20 trillion of them is a drop in the oceans, and nobody using a password generator is statistically likely to generate them within the expected lifetime of the universe, let alone of any given website. So, if you see one of those passwords, it is overwhelmingly likely that som…

No, it's not the correct conclusion. Virtually no passwords are safe under an offline brute force attempt if they haven't been protected by a robust key derivation function and a randomized salt. If the password has been protected like that, you not only need to try all 20 trillion of those hypothetical passwords; you also need to try them with the correct salt. And this is aside from the fact that you won't even rip…

But what is the harm in blocking all 20 trillion such passwords? Do you expect to have any false positives?

Re: Prevent users registering with passwords from data breaches

#17

Post by lytedev »

thaumaturgy wrote: post #2

You don't even need to call out to an external API to get good coverage for this rule, in case you're averse to doing such a thing. You can just do a case-insensitive match against this file that I compiled a while back: https://github.com/robsheldon/bad-passwords-index It includes the most commonly reused passwords according to in-the-wild breaches. I'm a bit embarrassed to see that it's been 2 years since the last…

This is a neat solution! My coworker documented how we mimic the PwnedPasswords API serving (lots of) static files: https://blog.benhaney.com/2018/11/04/recreating-pwnedpasswor...

Re: Prevent users registering with passwords from data breaches

#18

Post by greglindahl »

throwawaymath wrote: post #13
rmtech wrote: post #12

Earlier quoted context omitted.

If the password actually has a lot of entropy but it appears in a breach then that's some fairly strong evidence that the user is reusing it. Specifically if it appears n times in the HIBP database you should assign at least roughly 1/n probability that the user is reusing it. So if you assign disutility -V to letting a user have a known username + password combo and utility U to letting a user sign up with a known p…

> If the password actually has a lot of entropy but it appears in a breach then that's some fairly strong evidence that the user is reusing it. I'm not talking about scenarios where you can associate the password with a specific user.

Many people use the known passwords list with offline cracking tools.

Re: Prevent users registering with passwords from data breaches

#19

Post by throwawaymath »

simcop2387 wrote: post #9
throwawaymath wrote: post #8

Earlier quoted context omitted.

That doesn't make sense. If I publish a list of 20 trillion alphanumeric passwords, each of which is 20 characters long, your thesis is that no one should ever use any of those passwords again?

If it's published as a list of known passwords, yes. That's roughly 1.50463276905253e-21 percent of the potential passwords for that character space (assuming 64 possible characters). If it's know that those are passwords then they're much much easier to test against than the 1329227995784915872903807060280344576 possibilities.

First of all, in an online brute forcing scenario attackers will never get through the entire 20 trillion. Even if they knew for certain that the target victim's password satisfied the precise constraints of the passwords published in that list, they'd need around 2 years (with reasonable assumptions of millisecond latency) of constant, 24/7 attempts to run through them all. This is assuming there is no rate limiting.

In an offline brute forcing scenario, either the passwords have been hashed with a strong key derivation function and a randomized salt or they haven't. If they have, it doesn't matter if the password is in that list. If they haven't, you're most likely screwed either way, because attackers can get up to 1 trillion password attempts per second in real world cracking setups now.

Re: Prevent users registering with passwords from data breaches

#20

Post by rmtech »

throwawaymath wrote: post #13
rmtech wrote: post #12

Earlier quoted context omitted.

If the password actually has a lot of entropy but it appears in a breach then that's some fairly strong evidence that the user is reusing it. Specifically if it appears n times in the HIBP database you should assign at least roughly 1/n probability that the user is reusing it. So if you assign disutility -V to letting a user have a known username + password combo and utility U to letting a user sign up with a known p…

> If the password actually has a lot of entropy but it appears in a breach then that's some fairly strong evidence that the user is reusing it. I'm not talking about scenarios where you can associate the password with a specific user.

well when the password got breached it is associated with a particular user.

And HIBP will tell you how many times a given password appears, but not which account it appears with. See:

https://haveibeenpwned.com/Passwords

Post reply on HN