December 5, 2017 at 10:54 am #19955
Is it possible within OpenDJ / Directory Services to block known weak passwords to prevent users from using passwords that have previously been breached, or equally are just bad practice. I was hoping to use the ~300m passwords from Have I Been Pwned for this purpose, however as far as I can see it there are two problems:
December 5, 2017 at 11:03 am #19957JnRouvignacParticipant
- There isn’t a clear way of blocking passwords
- The passwords are stored as SHA1’s so it would require processing the user’s password and then looking it up in a hash table
The closest we have is https://backstage.forgerock.com/docs/opendj/3/configref/dictionary-password-validator.html .
Jean-NoelDecember 5, 2017 at 11:20 am #19958
Hi @jnrouvignac – thanks for your response, is the source code for that validator or another production ready validator available? shouldn’t be too difficult to build a custom validator that a list of hashes against a know list.December 5, 2017 at 11:32 am #19959JnRouvignacParticipant
Sure, have a look at https://github.com/ForgeRock/opendj-community-edition/blob/master/src/server/org/opends/server/extensions/DictionaryPasswordValidator.java .
Although FR version has diverged a bit from this code, I think you should be able to fill the missing pieces on your own depending on the version of the stack you are using.
December 6, 2017 at 8:38 am #19975LudoModerator
- This reply was modified 1 week, 3 days ago by JnRouvignac.
The password policy and specifically password validators, will prevent users from setting or updating passwords with weak passwords. In the latest release, we have a “dictionary” of bad or well known hacked passwords.
Now, I don’t know if the list of passwords available in “Have I Been Pwned” can be used to block weak passwords, since they are all hashed, possibly with different algorithm and salt. It might take a long time to check a user authenticating (or updating his password) against such a list of 300M + passwords.
With ForgeRock Access Management product, you can use the site to introduce some risk score with the use of such account and then request a second factor to better authenticate the user. This is not something you can do with Directory Services and LDAP as a protocol.
December 7, 2017 at 8:53 am #19990
- This reply was modified 1 week, 2 days ago by Ludo. Reason: Correction as Have I Been Pwned has a list of passwords available somewhere
The passwords available for download from “Have I been Pwned” are unsalted and hashed with SHA1 (some of the passwords contain personal data), there are strategies for efficiently storing and searching hashes so I’m not overly concerned about the performance considerations.
The question that your comment raises is about the most appropiate place to enforce a dictionary based password policy? Is it Access Management or Directory Services?December 8, 2017 at 2:53 pm #20015Andy CoryParticipant
IMO, enforcing a dictionary-based password policy is a job best done by DS, whether the dictionary in question is the built-in one, or the monster HIBP list. It’s a nice touch to look at Azure Table Storage to optimise that, too (or DynamoDB, I guess). My interpretation of Ludo’s comment was that an alternative to prohibiting a user from choosing a possibly compromised password would be to use AM’s adaptive risk auth module to require an additional factor each time if the user did choose such a password. If AM is making that decision based on feedback from the HIBP custom validator in DS, then I suppose both products are involved in enforcing the policy.
You must be logged in to reply to this topic.