2

The latest advice (e.g. from NIST) recommends that user's password are checked against known breaches and compromised passwords are forbidden.

What are some relatively straightforward steps that a regular web dev who is not a security expert can take to implement this? Just knowing what breaches to use and where to download them is a start. It would also be helpful to have an opinion on how far a typical site should go (e.g. it's probably not necessary to continually monitor breaches and update your list).

Edit: Mostly interested in non-SAAS approaches

paj28
  • 32,736
  • 8
  • 92
  • 130

1 Answers1

7

Perhaps the most popular password breach checking site, HaveIBeenPwned, supports a RESTful API which you can query as part of your password workflow. It allows you to search a subset of the password hash and returns a set of possible matches for you to compare against the full hash; see this section of the documentation.

Because HaveIBeenPwned is updated with new breaches as they become available, you do not need to worry about monitoring breaches to take advantage of them.

gowenfawr
  • 71,975
  • 17
  • 161
  • 198
  • But consider using a vpn for checking, otherwise your ip might be connected with that research and noone would realy want that – Dr3xler Dec 21 '19 at 23:09
  • @Dr3xler I don't see how a VPN will help, especially since the OP is talking about how a web application would check user passwords against a breach. Regardless, I don't understand what you are hoping to accomplish with a VPN, or what exactly you are worried about – Conor Mancone Dec 22 '19 at 01:20
  • Ok thanks. I think a lot of people would not be comfortable sending hashes to a third party. Your answer is useful, but hopefully someone else will suggest another way. – paj28 Dec 22 '19 at 06:40
  • The truly paranoid will download the entire corpus of pwned passwords... However, unless one considers Cloudflare to be _potentially_ malicious (which is reasonable, even if not expected), and considers Troy Hunt to be _probably_ suspicious (I've never met him; I can't vouch for him)... then using the general Pwned Passwords API as documented is good enough. (It's good enough _for me_: I use it to let my intranet users know how many times their passwords have been leaked, and remind them to use password managers, rather than follow SP 800-63B to its extremes while following its spirit) – Ghedipunk Dec 22 '19 at 07:32
  • 1
    And... every single _partial_ hash that is sent to the Pwned Passwords API identifies a few hundred -- perhaps up to a thousand -- known compromised passwords... while at the same time, also representing several hundreds of thousands (realistically speaking, that is... pedantically speaking: an infinite set, but overt pedanticism isn't useful in security) of potential passwords that haven't been leaked before. A malicious person involved in that API transaction might learn more, but not enough to make a meaningful guess at your users' passwords. – Ghedipunk Dec 22 '19 at 07:36
  • The point is, if the website got hacked, they might get your password in plain,but they cant connect it to your real ip, what is a positive thing – Dr3xler Dec 22 '19 at 09:24
  • @Ghedipunk - this partial hash sounds interesting. I will read up at silveri point, but can you ELI5? – paj28 Dec 22 '19 at 10:31
  • 1
    @paj28: How the Pwned Passwords API works is, you calculate an SHA-256 hash of the password. Then you take the first 5 characters of that hash and make a web request to `https://api.pwnedpasswords.com/range/[first 5 characters]`... I.e., https://api.pwnedpasswords.com/range/12345 . The result will return a list of all hashes that start with the first 5 characters you provided, and the number of times the password has been seen in data leaks. In the case of 12345, there are 553 known passwords that could be identified. – Ghedipunk Dec 23 '19 at 16:07
  • 1
    The way that an attacker could learn more is: If they already have the plaintexts of all passwords in Pwned Passwords (which Troy Hunt does, obviously), they know after witnessing your request that a user has a password with the first 5 characters of the hash result being 12345. In the 12345 results, there look like about a dozen with >100 matches, and one with 709 matches. If you were to build a customized dictionary to attack the passwords of my users, you would use the passwords that had been re-used the most. – Ghedipunk Dec 23 '19 at 16:13
  • 1
    The [NIST standards section 5.1.1.2](https://pages.nist.gov/800-63-3/sp800-63b.html#sec5) states `When processing requests to establish and change memorized secrets, verifiers SHALL compare the prospective secrets against a list that contains values known to be commonly-used, expected, or compromised.` Bullet points below that line give examples, including compilations of previous breaches, which is what PP does. The NIST standards says to reject the password; instead (I'm in the same office) I show the results to the users and let them come to me, where I teach them about password managers. – Ghedipunk Dec 23 '19 at 16:17