
Prevent users registering with passwords from data breaches - DivineOmega
https://jordanhall.co.uk/prevent-users-registering-with-passwords-from-data-breaches
======
dwighttk
I need password fields to:

1)not silently fail when I try a 64 character (or 32 character) password

2)not fail and say my password is "too short" when it is 32 characters and you
have an unrevealed maximum password length of fewer characters than that.

3)just all-around quit failing when my password is totally fine, it's a quasi-
random string of letters, numbers, and symbols and I'll never type it...

oh yeah

4)don't disable pasting in the password field

4b)IF you do, freaking let me see what I've typed. I promise to not enter the
password in a place someone can shoulder surf. Trust me that's WAY down on the
threat list for my life.

Then, and only then, if you really want, keep me from registering with a
breached password. But you had better tell me that is what is going on.

~~~
0db532a0
There’s something that I don’t really understand regarding password managers
which maybe you could explain. How is using a password manager to manage
multiple passwords more secure than using a single password everywhere?

In the case of a password manager, if your computer is breached, then all
passwords are breached. If your passwords are hosted encrypted on a website,
then if that website is breached, the master password you send it will be
visible to the attacker, and thus all passwords are breached.

In the case of using the same password everywhere, if one website is breached,
then the password to all sites is breached.

Am I missing something?

~~~
zeeZ
If your computer is "breached" then it doesn't matter where your passwords
come from. They could just run a keylogger and get them that way.

It really depends on your threat model. No system is perfect and we're mostly
balancing security and convenience most of the time.

The same password everywhere is super convenient, but only one site needs to
fail and it's all over. A cloud password manager with unique passwords protect
from that. A local password manager eliminates the threat of them being
compromised, but is less convenient if you have multiple devices. Storing your
passwords offline on paper in a safe protects your from someone getting read
access to your PC or outright stealing it, but is annoying and gets more
inconvenient based on your passwords entropy.

------
hannob
All of those rely on Troy Hunt's API. Which may be fine for some people, yet
others may uncomfortable introducing an external dependency. I generally
recommend avoiding external API dependencies if you can.

Here's a python implementation using bloom filters which avoids storing the
whole list (need to store ~1 gig), yet still gives you very good accuracy:
[https://gist.github.com/marcan/23e1ec416bf884dcd7f0e635ce5f2...](https://gist.github.com/marcan/23e1ec416bf884dcd7f0e635ce5f2724)

It's more what I think this should look like.

~~~
bartread
Tend to agree on third party dependencies. They're a useful leg up if you're
just prototyping, testing an idea, or generally groping around for
product/market fit, but I'm not in love with them as a long term solution -
certainly not for anything that's core to your product or service.

Too many potential pitfalls:

\- If their service goes down, you may go down too, or you have the added
complexity of gracefully handling the situation when they're down

\- You have no control over their roadmap... which means you might suddenly
get a bunch of non-value-adding but totally essential work dropped into your
backlog, and perhaps at short notice, because of changes they make

\- Perhaps they go out of business or, for whatever reason shut down their
service: again, congratulations, you've just got a load of work you didn't
bank on getting in the way of delivering your own roadmap

I think most of us have probably seen multiple examples of the above, if not
at first hand, then posted on HN or elsewhere on the web.

I'm not an NIH kind of guy but I do tend to prefer libraries, or co-located
installs for long-term dependencies. That way at least you can _manage_
migrations and updates according to your own agenda rather than somebody
else's.

------
air7
This is over the top. Even enforcing password complexity is over-rated.

For online attacks, an attacker can't even try the top 1000 passwords on for
an account in any major website in reasonable time without triggering the
alarm, as they all(?) have rate limiting (usually in the form of account
lockdown after single-digit failed attempts).

For offline attacks, there first needs to be a breach. While they undoubtedly
happen, they are very infrequent events. But once they happen, you should
assume all passwords would be cracked very fast. Hackers can get their hands
on a lot of computing power, and the brute-forcing attempts are not
alphabetical, but rather clever how-humans-chose-passwords models. You're
relatively safe because of the low frequency of breaches, not because a hacker
trying trillions of passwords a second will be frustrated by your password
choosing policy. I'm sure most of the passwords from the breaches would be
attempted anyway.

Credential stuffing[0] is the real issue. If there was an API to test that a
user isn't using this password on other websites, _that_ would be very useful.

[0]
[https://www.owasp.org/index.php/Credential_stuffing](https://www.owasp.org/index.php/Credential_stuffing)

~~~
hombre_fatal
Our solution for a bitcoin casino was to generate passwords for users. But you
can imagine how few sites can get away with such a thing. Our create-password
input was a disabled textfield with a reroll button.

Before that, attackers would just wait for new usernames to appear on the
scoreboard/chat and check them against password dumps. The easy come, easy go
nature of bitcoin made it particularly lucrative.

Password reuse is a massive issue. At a glance, one might wonder why most
sites need to care so much since they don't deal with money. Who cares about a
forum like HN? But consider that it's easier to audit/impede new accounts with
anti-spam measures, so there's value in taking over old accounts. And you
don't want people with moderation tools getting attacked either. Ideally, it's
nice to be able to trust an account with 1,000 posts more than one with 0
posts, but that evaporates when accounts are easily stolen.

Aside, how do you implement account-locking without making it trivial for
users to DoS each other that way?

~~~
air7
> Aside, how do you implement account-locking without making it trivial for
> users to DoS each other that way?

By adding an (increasing) time delay after each failed attempt. However many
sites, banking in particular, just lock your account and you have to call them
on the phone to reopen it. Totally open for massive DoS but the world still
stands.

~~~
hombre_fatal
Well, that introduces trivial DoS, so it doesn't satisfy my question.

Notice that banking websites can get away with it, yet surely you weren't only
talking about banking when you said "online attacks".

~~~
air7
Sorry, I tried to say 2 things: 1\. Your simple solution: add a 5 second delay
after each failed attempt per username OR ip address. 2\. It seems that sites
that do account lock-outs don't suffer from DOS attacks, for some reason.

------
cpburns2009
And I thought we were getting away from arcane rules for passwords. Now you
have to avoid every compromised password from any unrelated account? I may use
random passwords, but I don't expect the typical consumer to do the same.
Sometimes I simply don't care about security for a one off account on a free
service where I'll happily use the simplest permutation of "password" for the
password.

~~~
geofft
The existence of password breach databases means that attackers are already
attempting other people's passwords against your accounts.

We should honestly move to the world where typical consumers are using
password managers that generate passwords randomly. I think it is pretty
reasonable to expect the typical consumer to install and use a password
manager; I think it's pretty _unreasonable_ to expect the typical consumer to
generate memorable, strong, and unique passwords for each website and store
them in their head.

~~~
blackflame7000
Realistically even a dictionary attack for a login service should have some
sort of flag after repeated incorrect passwords or at least be rate limited to
some degree. It would really only be bad if they gained access to your hashed
passwords database table because then the dictionary attack would immediately
hit for some weak passwords. I argue that access to the hashes shouldn’t be
allowed in the first place.

------
thaumaturgy
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](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 update. I
was thinking recently about updating this again. I think I'll do that.

~~~
lytedev
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...](https://blog.benhaney.com/2018/11/04/recreating-
pwnedpasswords-api)

------
CM30
So what happens when a significantly large percentage of 'standard' passwords
are disallowed and your average Joe just can't be bothered to create another
one?

Seems like eventualy you'll end up driving away everyone who isn't tech
savvy/doesn't use a password manager/randomly generated password, which seems
like something that'll significantly limit your site or app's audience.

I get the logic behind it, and it's a neat idea on a security level, but it
seems like a guaranteed way to drive your userbase to your competitors by
making it annoying to sign up.

~~~
pbhjpbhj
If you need your users to have a secure password then that's a good thing. We
need to make password managers simple enough, and default, for all users.

------
draugadrotten
What is the latest and greatest in password creation rules anyway? It is hard
to define a password policy which covers both users' practical needs and still
makes ERP systems secure and follows best practice of the major players.

Microsoft research has an interesting paper on it. Are there more like this
out there? [https://www.microsoft.com/en-us/research/wp-
content/uploads/...](https://www.microsoft.com/en-us/research/wp-
content/uploads/2016/06/Microsoft_Password_Guidance-1.pdf)

Hints welcome!

------
21
This is a terrible idea which will backfire.

Many users have a "universal weak password" for sites that don't really
matter, now you will be forcing them to jump through hoops just because so.

~~~
geofft
I suspect there's a relatively small window of folks who have a universal weak
password. There are lots of folks who have a universal password for
_everything_ ; there are some folks who have a unique password for everything,
because once you use a password manager or even a password scheme you might as
well customize your password for every site.

And I think forcing people who are in a position to use unique passwords
easily, but too lazy to do so, to get around to using unique passwords is a
good thing to do. I include myself in this category - I was sloppy at password
hygiene until very recently and I should have gotten on it a long time ago.

(Note that I'm not endorsing password schemes because they're very vulnerable
to targeted attacks, but they are popular and arguably easier than password
managers and they do technically count as letting you use a unique password on
each site - if you use one, the HIBP API will not block you from logging in to
any sites other than the one that got breached.)

------
jperry2019
It might be frustrating for users to have their typed password rejected
without an explanation. Since there’s no authoritative list of compromised
passwords they would have to take your word for it.

Wouldn’t a better solution be to increase password requirements until users
are forces to generate one using a password manager? If you can memorize a
password it’s probably not secure.

------
blackflame7000
I feel like if they have already managed to gain access to your hashed
passwords 9/10 times its already game over

------
masa331
Please don't use passwords at all. They are wrong for so many reasons. Use
emailed sign-in links.

~~~
pbhjpbhj
Which, in general rely on your users email password .. which may not be as
secure as their bank password, because "email doesn't handle money".

So, to access your bank now crackers just need to get in to your email (which
may be true anyway, of course 2FA helps in both cases).

~~~
masa331
If somebody get to your email you are doomed anyways because with passwords
all they have to do is reset it through that hacked email.

The benefits of sign-in links are: a) you don't have to remember gazilion of
passwords b) you don't have to use password managers c) you can setup a really
strong passphrase for your email and actually remember it because it's the
only one you have to. And of course set up strong MFA or whatever d) you don't
have to setup MFAs on services and giving them more personal info(phone
number) than they really need e) for me as a developer it's also easier to
implement actually

------
MarkMc
If you say to the user, "sorry but that password is too common - please try
again" then the user will simply add a 1 to the end of the password and press
submit. That doesn't offer much improvement in security.

~~~
mnutt
If that happens commonly, the original password with a 1 appended will
probably eventually appear in a future HIBP database. In fact, the user could
continue adding 1s until they either give up and try something different, or
until it becomes uncommon enough.

~~~
MarkMc
Here's an example of that user experience:

User: Set my password to 'monkey'

Website: Sorry that's a common password

User: OK, set my password to 'monkey1'

Website: Sorry that's a common password

User: What?! OK, set my password to 'monkey123'

Website: Sorry that's a common password

User: Grr! Set my password to 'monkey123fuckyou!!'

Website: Sorry that's a common password

User: Screw this, I'll just sign up to your competitor's website instead

~~~
tialaramex
But with Pwned Passwords after that last attempt it just works. Because your
scenario is imaginary and you haven't actually checked these were all
backlisted. Whether the user will remember they picked "monkey123fuckyou!!" is
a good question, but it's a markedly better password than "monkey".

------
throwawaymath
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've just "breached it" by posting it
on Hacker News.

~~~
rmtech
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.

~~~
throwawaymath
_> 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.

~~~
geofft
You can in fact associate the password with a specific user - the fact that
that exact password is being reused is, _by itself_ , strong mathematical
evidence that it's the same user or someone they told the password to, because
it is basically mathematically impossible that anyone else could generate the
same password by coincidence (unless they're both using a password generator
that doesn't have good random seeds or is otherwise deterministic, in which
case you should be banning the password anyway).

~~~
rmtech
> exact password is being reused is, by itself, strong mathematical evidence
> that it's the same user

yes, exactly.

~~~
geofft
I thought of another way of putting this - a 20-character alphanumeric
password is a random 114-bit value. A UUIDv4 is a random 122-bit value (the
remaining bits are specified by the UUID spec). If you generate UUIDs for your
users, and you don't expect two users to end up with the same UUID, it would
be confusing if you somehow expected two users with 20-character alphanumeric
passwords to potentially collide. The probabilities are just a factor of 256
from each other.

~~~
Dylan16807
(119 not 114, there are 62 alphanumerics)

------
rmtech
Just a quick point that is worth considering: If a user types in a password
and that password appears once in the HIBP breach list, then it is extremely
likely that the source of the password in the breach list IS that user.

If it appears 2-3 times, then there is still a significant chance that that
user is the source of the password getting into the HIBP database.

And if that user is the source, then the bad guys most likely know that user's
email and password, and their account is wide open.

~~~
scarhill
Exactly. I think of the HIBP password list as having three types of passwords
(this is an oversimplification, but bear with me):

1) Extremely weak ones that lots of people use (e.g. 'password1') 2) Somewhat
unique ones (their pet's name and birthday) 3) Truly strong ones (random, long
strings)

I don't want users on my site using type 1 passwords at all. If a password is
really type 3, the odds say that no user will ever try to use it again, so
there's no collateral damage in blocking it. The person signing up with a type
2 is almost certainly the same user whose credentials are in the breach. I
don't want them to reuse that password on my site because it makes their
account vulnerable to credential stuffing.

------
scoot_718
So they'd have to be testing in the browser. Seems unlikely.

------
CamperBob2
That is going to be insanely annoying.

~~~
scarhill
Could you explain? Unless you're using a really weak password or reusing
passwords, how would it affect you?

~~~
CamperBob2
I do, in fact, use really weak passwords on sites where it doesn't matter, and
I reuse them whenever I feel like it.

Passwords already suck. Please don't make them suck even more.

