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?

schroeder
  • 125,553
  • 55
  • 289
  • 326
Toby Smith
  • 531
  • 1
  • 4
  • 7
  • 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 '19 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 '19 at 07: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 '19 at 07: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 '19 at 07:58
  • 3
    FYI: The Nextcloud personal cloud software allows an admin to enable HIBP password checking [in the user password policies](https://docs.nextcloud.com/server/16/admin_manual/configuration_user/user_password_policy.html). – Dubu Jul 26 '19 at 09:53
  • Comments are not for extended discussion; this conversation has been [moved to chat](https://chat.stackexchange.com/rooms/96748/discussion-on-question-by-toby-smith-is-there-a-reason-why-i-should-not-use-the). – Rory Alsop Jul 29 '19 at 09:19
  • Make it a checkbox option for users to decide. – eych Jul 31 '19 at 18:06

6 Answers6

71

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.

Conor Mancone
  • 30,380
  • 13
  • 92
  • 98
  • 1
    @ConorMancone thanks for the edit, and is what I was hoping you'd include. Just throwing "good things to do" at a service is never a good idea. There needs to be a benefit to the cost. – schroeder Jul 25 '19 at 19:56
  • 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 '19 at 12:54
  • @Woohoojin Good point, although I consider that to simply be an additional "cost" of implementing the feature, so I've mentioned it in point #4. Thanks! – Conor Mancone Jul 26 '19 at 13:03
  • 8
    @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 '19 at 13:56
  • 1
    That's a good idea @MatthieuM., this is a feature we want to re-enable on our site at some point. Maybe that will let us avoid the additional user friction. Sad we live in a world where so many people couldn't care less about security. – Woohoojin Jul 26 '19 at 14:09
  • 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 '19 at 14:17
  • @woohoojin security is always a tradeoff of convenience, and sometimes the cost of security isn't worth giving up convenience if there's nothing to protect. Lots of people have a throwaway password for sites that don't really matter because it's easy, and they still use secure passwords when it matters. – Kat Jul 26 '19 at 16:34
  • Are there no concerns about sending every new user's password to a third party, or do you just trust Troy Hunt and all his employees & service providers to have that data? – WBT Jul 26 '19 at 18:34
  • 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 '19 at 18:50
  • 1
    @WBT: You can also download the whole database, if you would rather do the check without a dependency on HIBP's WS availability. – Jean Hominal Jul 26 '19 at 18:51
  • 1
    @ConorMancone That's a useful point! I suggest editing it into the answer for folks like myself who haven't yet read into the operational details of exactly how the API works. Jean also makes a good point about the introduction of a new dependency, and a potential mitigation strategy. – WBT Jul 26 '19 at 18:53
  • 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 '19 at 19:47
  • @Woohoojin so your website is not important enough to be worth a harder-to-remember password. Plenty of websites require signup that shouldn't. – user253751 Jul 06 '21 at 15:39
15

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.

Dmitry Grigoryev
  • 10,122
  • 1
  • 26
  • 56
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.

WoJ
  • 8,968
  • 3
  • 33
  • 51
  • 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 '19 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 '19 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 '19 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.

gnasher729
  • 2,107
  • 11
  • 16
  • 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 '19 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.

noɥʇʎԀʎzɐɹƆ
  • 416
  • 1
  • 3
  • 15
  • 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 '19 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.

Nicole Murdoch
  • 1
  • 2
  • 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. –  Jul 28 '19 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 '19 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 '19 at 07: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: https://www.lexology.com/library/detail.aspx?g=b41761fb-4ae6-49ae-b238-349a45aacb62 – Nicole Murdoch Jul 29 '19 at 09:28
  • The Lexology link has a register wall – schroeder Jul 29 '19 at 09:40
  • Your justifications for site-side protections do not apply in the situation posed by the question. Blocking users from using passwords from a breach list does not make the site more secure. – schroeder Jul 29 '19 at 09:42
  • I don't think he is saying that he is checking it against a list of known passwords - I think he is asking if he can check if a user is trying to reuse credentials that are known to be breached – Nicole Murdoch Jul 29 '19 at 10:00