Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Blacklist common passwords #832

Open
alexweissman opened this issue Dec 17, 2017 · 14 comments

Comments

Projects
None yet
6 participants
@alexweissman
Copy link
Member

commented Dec 17, 2017

Together with minimum length, blacklisting common passwords is the most effective known password policy.

Not sure how many we should blacklist by default.

Probably, we should also enforce an entropy requirement and blacklist password = username and password = email. See https://blog.codinghorror.com/password-rules-are-bullshit/

@Silic0nS0ldier

This comment has been minimized.

Copy link
Member

commented Dec 22, 2017

Probably (definitely?) overkill, but https://haveibeenpwned.com/Passwords has a known exposed passwords list. All encoded in SHA1 (cause there are people out there that have passwords that identify them 🤦‍♂️). Pity it has no frequency with them.

@splitt3r

This comment has been minimized.

Copy link
Collaborator

commented Apr 25, 2018

@Silic0nS0ldier awesome idea. nextcloud/password_policy#60 This is a good example / an easy way of getting started.

@Silic0nS0ldier

This comment has been minimized.

Copy link
Member

commented Apr 25, 2018

Since you've reminded me, there is a password manager that has since integrated with the service. And based on Troy Hunt's blog posts, the API endpoints are highly optimised (most requests don't get past the CDN which Cloudflare footed the bill of) so any potential bandwidth theft implications are essentially eliminated.

Hmm... What would be the best place to perform the check? Server-side or client-side?

@lcharette

This comment has been minimized.

Copy link
Member

commented Apr 25, 2018

If you rely on a 3rd party API, we should consider caching the info on our side using the cache service. Then it's either a question or doing the check in either form validation (client or server side).

@Silic0nS0ldier

This comment has been minimized.

Copy link
Member

commented Apr 30, 2018

Update regarding the API: only anonymous requests will be accepted in the future.

The anonymous API works by giving the first few characters of the hash, and receiving hashes that match in return (minus the characters that were sent originally).

@Silic0nS0ldier

This comment has been minimized.

Copy link
Member

commented Nov 14, 2018

On the topic of caching, we'd need some system to keep the size to a reasonable amount. We could also limit caching to common results, since each hashed password is paired with a number indicating the number of items its appeared. I'm sure one of Troy's blogs has a graph we can use to get an idea of what a good number would be.

@Silic0nS0ldier

This comment has been minimized.

Copy link
Member

commented Nov 17, 2018

Some things to consider are mentioned here https://twitter.com/alexjamesbrown/status/1063552695133487104

@amosfolz

This comment has been minimized.

Copy link
Contributor

commented Apr 27, 2019

Probably (definitely?) overkill, but https://haveibeenpwned.com/Passwords has a known exposed passwords list. All encoded in SHA1 (cause there are people out there that have passwords that identify them 🤦‍♂️). Pity it has no frequency with them.

I have been playing around with this idea to see what I can come up with. I am having a hard time trying to determine if it would really be worth using this with the cache service or not? Would the purpose of that just be for server-side validation?

@Silic0nS0ldier

This comment has been minimized.

Copy link
Member

commented Apr 28, 2019

Cache service would be to minimise the total amount of bandwidth consumed (have to consider HIBP and the site making the request if server side) and cut out an extra request where we can.

As for if it should be server side or client side enforced... Sounds like something that should be configurable. Personally a requirement is my preference. Also worth considering if we want to do the check at login, to keep accounts having a secure password.

@amosfolz

This comment has been minimized.

Copy link
Contributor

commented Apr 30, 2019

Would the best place to store configuration options for something like this be inside the site variable? Options could be added under something like site.password_security

@lcharette

This comment has been minimized.

Copy link
Member

commented Apr 30, 2019

Depends if you want to store the base config (on /off switch) or the whole list in that config. If the list is long, or dynamically loaded, it might not be the best place. The site config is pushed into every request. Putting too much in the site config could add unnecessary overhead.

I think for this kind of feature, server-side only check could be enough.

We need to be careful with the HIBP list. More then 7 GB of data 😱

@amosfolz

This comment has been minimized.

Copy link
Contributor

commented Apr 30, 2019

Depends if you want to store the base config (on /off switch) or the whole list in that config. If the list is long, or dynamically loaded, it might not be the best place. The site config is pushed into every request. Putting too much in the site config could add unnecessary overhead.

I think for this kind of feature, server-side only check could be enough.

We need to be careful with the HIBP list. More then 7 GB of data 😱

Yes I think just the base config would be stored there. Just as an example I have this so far:

  'password_security' => [
                'enforce_no_compromised'   => '5', // Set to false to turn off this feature. Otherwise, provide a numeric string, which sets the maximum number
                                                   // of times that is "acceptable" for a password to have appeared in breaches. The recommended and most secure
                                                   // option is '0' - meaning only passwords that are not on the list of compromised passwords will be allowed.
                                                   //
                'enforce_update_passwords' => true // Settings this to true will check user's passwords against list of known compromised passwords at each log on.
            ]

A short refresher on how the HIBP API works: It uses a k-anonymity model. So, you send the first 5 characters of SHA1 hash of password, and get back a list of hash suffix. Then you compare the long list of hash suffix with your actual password hash suffix. Their website states the smallest result is 381, the largest 584.

@lcharette

This comment has been minimized.

Copy link
Member

commented Apr 30, 2019

Oh, so you don't have to fetch the whole list... makes sense...

@obendev

This comment has been minimized.

Copy link

commented May 21, 2019

I can recommend the Nextcloud example. As being said they also use haveibeenpwned

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.