Blocking Weak Passwords through OpenDJ / Directory Services

This topic has 6 replies, 4 voices, and was last updated 4 years, 8 months ago by Andy Cory.

  • Author
  • #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:

    1. There isn’t a clear way of blocking passwords
    2. 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

    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.


    Sure, have a look at .
    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.

    • This reply was modified 4 years, 8 months 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.

    • This reply was modified 4 years, 8 months ago by Ludo. Reason: Correction as Have I Been Pwned has a list of passwords available somewhere

    Hi Ludo,

    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?

     Andy Cory

    Hi Richard

    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.


Viewing 7 posts - 1 through 7 (of 7 total)

You must be logged in to reply to this topic.

©2022 ForgeRock - we provide an identity and access platform to secure every online relationship for the enterprise market, educational sector and even entire countries. Click to view our privacy policy and terms of use.

Log in with your credentials

Forgot your details?