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

Improve this question

1 Answer 1

Reset to default
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.

Improve this answer
11
  • 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, 2019 at 23:09
  • 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, 2019 at 7:36
  • 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., 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, 2019 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, 2019 at 16:13
  • 1
    The NIST standards section 5.1.1.2 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, 2019 at 16:17

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .