62

There's lots of talk about the HaveIBeenPwned password checker which can securely tell users if their password appears in one of their known data dumps of passwords.

This tool has a publically available API behind it which websites/apps/etc are free to use to allow their users to check their passwords, but from what I can see all the listed applications are specifically email/password checker tools.

Never have I seen or heard of a user entering a password into a website while creating an account and it then gives them an error message detailing that their chosen password can be found in a well-known data breach.

If I were to create a website, would it be a bad idea to automatically check my user's passwords against HaveIBeenPwned's tool as an additional safety precaution and to require them to pick a password which the site doesn't know about?

  • 3
    For your first question: There are too many reasons to count, including ignorance of the service, distrust, different company priorities, etc. That part is far too broad for this site. For your second question: The NIST standards suggest using such a service, though doesn't name the Pwned Passwords API of HIBP. It's up to you to do a cost/benefit analysis, threat assessment, etc., to see if it's right for you, or even if following the NIST standards is right for you; though we'll certainly be happy to give our opinions if this question's scope were reigned in a bit. – Ghedipunk Jul 25 at 19:29
  • I have edited your question to reflect that you want to know if you should not do it, instead of asking why others have not. The votes to close this question as "too broad" were high. That's why I asked you to edit this. – schroeder Jul 26 at 7:07
  • 4
    I think using a service is a bit problematic as you have to send user passwords to third parties (they might be simply hashed but unsalted Sha1 or ntlm Hashes are a very weak protection). Unfortunatelly checking the lists offline means you need to have gigabytes of password Hashes. – eckes Jul 26 at 7:29
  • 47
    @eckes - Neither the password or a password hash are sent to HIBP for this system to work. The client hashes the password and sends the first 5 characters only to HIBP. The response contains all of the hashes which begin with those characters which the client can then check the full hash against. The password and the hash both never leave the client and HIBP never knows the password, it's hash, or if the password was a match or not. – Toby Smith Jul 26 at 7:58
  • 3
    FYI: The Nextcloud personal cloud software allows an admin to enable HIBP password checking in the user password policies. – Dubu Jul 26 at 9:53
74

Latest recommendations from the NIST (SP 800-63b Section 5.1.1.2; see here or here for a summary) actually suggest checking user passwords against lists of known compromised passwords, so doing just that is actually in line with current best practices. It's also much better than requiring passwords to meet certain "rules" (which the NIST now recommends against). HIBP is just one way (and probably the simplest way) of doing this in practice. It only requires sending off the first 5 letters of the hash of the password, so actual risk to users is practically zero. So yes, please feel free to do it if desired.

As for why a particular organization might not do this, I'm sure that varies wildly from site-to-site, but I think it's a safe bet that it boils down to the usual suspects:

  1. Security is an area where many like to skimp, and implementing such a system takes additional effort.
  2. It takes time for new best practices to become common knowledge for institutions
  3. It takes even more time for institutions to get caught up with best practices
  4. Every developed feature has costs: money in terms of engineering time to develop and maintain, lost users who don't understand or wish to follow the rule (h/t @Woohoojin), etc. Organizations may not consider the added benefits to be worth the costs.

To be fair, none of my systems do this yet, so you can add me to #3 or #4.

Item #4 is worth a bit more mention. The costs of implementing this are obvious—it takes developer time to build and maintain any feature. The benefits are much harder to quantify. Of course when it comes to security issues, many companies make the mistake of assuming benefits are zero and therefore skimp on security (see point #1). However, this is one feature in which the benefits are likely small. There are often real costs to a business related to the compromise of user accounts (more customer support, perhaps rolling back transactions, etc...), but as long as the compromise was due to the user's own mistakes (in this case, by choosing compromised passwords), a business is unlikely to see any direct liability and therefore will probably avoid any larger costs. As a result, features like this may not be worthwhile for all businesses to implement—it's always up to each business to weigh for themselves potential costs and benefits.

  • 26
    @ConorMancone I believe there is a 5th reason it may not be implemented. My website actually used to do this, and I discovered users would rather not register for an account on my site than use a new password, when they were not allowed to use their insecure password. Since my website happens to not be storing anything sensitive on my users, I decided to remove the feature in order to decrease the likelihood that I would scare users away. – Woohoojin Jul 26 at 12:54
  • 7
    @Woohoojin: I think this is one thing that Stack Overflow got right, you can start using the site without creating an account, which minimizes the initial friction, and when you become serious, you can "convert" your on-the-fly account into an authenticated one. – Matthieu M. Jul 26 at 13:56
  • 2
    @Woohoojin I can believe that some users wouldn't bother with a site that didn't let them re-use a hacked password; FWIW for some sites, security probably just doesn't matter at all for the user, there were a couple times I registered for a forum or one off site that insisted I made a login just to download something one time, I used a throwaway e-mail and a lame password for that (not just out of laziness but also because if the site got hacked I might lose a good password) – jrh Jul 26 at 14:17
  • 2
    @WBT No passwords are sent - just the first 5 characters of the hash. For a number of reasons, this brings the risk down to virtually zero. – Conor Mancone Jul 26 at 18:50
  • 2
    @Woohoojin, in the application where I used the Pwned Passwords API, I still let the user register with the password, but I show them a message saying how many times the password appears in the lists that Troy Hunt uses, with a link to HIBP so that they can check for themselves. It's a tool used in house only, though, and all 10 of the users know me by name, so I use it as a user education opportunity more than anything. – Ghedipunk Jul 26 at 19:47
14

Because the cost of doing so is non-trivial:

  • people who don't understand how HIBP works will assume that you're not handling the passwords properly (example), and you'll have to deal with complains and misguided criticism.
  • you'll have to periodically update the code when HIBP API changes, or the service shuts down and you'll have to migrate to a new one.
  • any slowdowns or downtime on HIBP will mean your own site will slow down. Especially if you want to keep checking existing passwords against new breaches.

At a later time, it is likely that such a feature will be expected from a website which claims to take security seriously. Then everyone will be implementing it because the costs outlined above will be outweighed by the benefit of looking like a secure website.

And yes, there are companies who have already implemented the HIBP check.

4

You did not put a country tag, which can influence what you can do or not. You seem to be from the UK, though - which apparently has a more relaxed way regarding the points below.
Also you seem to want to do the check at login time - that would make my comments below less useful.

All this said, taking the example of France or Germany, you need to be extra careful presenting a solution which tracks users' activities. You can have the best intentions in the world, there are some people who will not appreciate.

Specifically, if you are checking leaks against the users professional email you are fine (I am assuming you work in information security for that company). You have an obligation to protect the interests of your company so if a professional email (and possibly the associated password) is being misused then you are in the green.

Be careful extending this check to non-professional activities. You may want to suggest people to check themselves their personal emails against HIBP but that's all.

YMMV - this is a consensual position I took after zillions of discussions with legal, privacy and labour law experts; each of whom had their own opinion on the subject so I am treading lightly.

  • 1
    That's interesting, I hadn't considered that location could be a factor in this. The checks in this case wouldn't be against emails however, they would only be for the passwords against known password dumps. – Toby Smith Jul 26 at 14:00
  • 2
    The proposed check isn't really related to email addresses or any other PII - it (as far as I understand) would involve verification of the hash of the proposed new password (whenever a user sets or resets their password) to check whether it should be considered weak because it's previously exposed on other sites. Essentially, verifying if your proposed password is in a "blacklist", not checking whether your email address (which is PII) has been compromised; the address isn't used at all, the plaintext password isn't exposed, only the hash, and even that is verified with k-anonymity. – Peteris Jul 27 at 10:43
  • @Peteris: yes, this is what I wanted to convey with the last line of my first paragraph. My answer is just to share some extra verification to do in case the final solution would finally be PII-related. The ide of verify if a password is "fine" is excellent on its own. – WoJ Jul 27 at 11:57
-2

If I enter a password, you should not hand it over to a third party under any circumstances. Even in hashed form. It will always give an attacker an opportunity.

Now if you can get a complete copy of the password database, and store it together with the rest of your password handling code, so that it can be checked without any outside communications, that could be worthwhile.

  • 9
    That's not how the system works. As I detail in a comment on the question, only the first 5 characters of the hash are sent to HIBP. The response containts all if the breached passwords in hashes which begin with those 5 characters. The client then checks if the hash is in that list. HIBP never get your password or hash, and they never know if your password is a match or not. – Toby Smith Jul 27 at 20:17
-2

No, because by sending the SHA-1 of the password to a third-party (HIBP), you are exposing your users to MITM attacks. SHA-1 is not secure against a well-funded, nation-state attacker.

The authors of the linked paper estimated the cost of mounting such a SHA-1 collision attack to be $75,000, assuming prices from a public cloud services. However, you could perform the same computation on a supercomputer for only $1,395.60, a small sum when the stakes are high. Based on the leaked information about the user, the following could happen:

Such an attacker could wiretap the target's traffic, then later sort through the contents of the traffic to look for weaknesses.

Readily available consumer tools can sniff, intercept, and modify HTTPS traffic. Unless, HTTPS certificate pinning is used and that certificate is not compromised, a determined nation-state attacker can use a compromised CA to intercept HTTPS traffic.

A better way to do it is to have a database of cracked password hashes on the server that you use to verify passwords.


The first 5 characters is too much information to give away. It raises attacker cost. That turns a secure password into something crackable.

  • 4
    This is a well intentioned but completely wrong answer. Research HIBP better. (1) You don’t send any part of the password there, you send 5 characters of the hash, and (2) you can download the hashes from hibp so as not to have to do even that. – Wildcard Jul 28 at 18:59
-3

Not only to make your users more secure but it makes your site more secure as well - if your (emphasis added for clarity) users are breached it will reflect on you (because it is your platform that might be attacked due to user credentials being compromised) regardless of whether the weakness is with you.

It secures your platform and the information you hold as much as it secures your clients. Under the Australian Privacy Act, if you fall under the Privacy Act you are required to keep the personal information you hold - secure. Hold is defined as control or possess. So companies are being found to breach the Privacy Act even though it was a third party breach that occurred because they "owned" the data - source see the Blood Cross comments by the Privacy Commissioner - https://www.oaic.gov.au/updates/news-and-media/australian-red-cross-blood-service-data-breach/

So cloud providers are just as responsible for the breach as the SAAS provider they host and people who's credentials were compromised. Even though they might not control security around the servers etc. Welcome to Australia!

Therefore by increasing security around your platform you are protecting yourself - assuming you have similar laws.

Also, it serves as an education to users - they learn that reuse of credentials is not safe.

  • 2
    This answer doesn't add anything that hasn't already been said. Your claim of having met Troy Hunt isn't verifiable, and the fact that you consider him trustworthy doesn't mean anyone else has to. – MechMK1 Jul 28 at 10:40
  • It educates staff members and can be used as a tool to spread the security message. I had previously listed my credentials but the Mods didn't like it so I stopped listing them. – Nicole Murdoch Jul 28 at 10:44
  • "if your users are breached it will reflect on you" - citation needed. Users do not blame the vendor if their individual accounts are hacked. "they learn that reuse of credentials is not safe" - citation needed. This process and communication is not likely to result in users walking away with the idea that password reuse is not safe. There are a lot of dots to connect for someone to come to this conclusion. – schroeder Jul 29 at 7:03
  • I meant if the company is breached because of email credential compromise. Which does happen - look at the issues with Pexa in Australia - the fault was that of the convenyancers that simply use the Pexa platform. But Pexa was blamed - so much so that it brought in a residential sellers guarantee. - Source: lexology.com/library/… – Nicole Murdoch Jul 29 at 9:28
  • The Lexology link has a register wall – schroeder Jul 29 at 9:40

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.