Skip to main content

Password Storage in OpenDJ

A common use case, is the migration of user profile data to OpenDJ.  Especially in large scale consumer facing identity projects, most clients already have repo's that contain user profile data.

Sometimes these stores also contain authentication data - that is the user name and password of the individuals.  Migrating data is relatively simple in this day and age regardless of whether that is identity data or not, but a common issue regarding login credentials, is how to migrate without impacting the login process.  For example, you don't necessarily want to get every user to reset their password for example, when they migrate to the new system.

Within OpenDJ this fortunately isn't a big deal.  A reason users might have to reset their password, is often to do with how the password has been stored on the source system.  When it comes to passwords there are generally two main approaches - symmetric encryption and hashing.  Symmetric encryption (meaning the password can be decrypted using the same encryption key) is seen a less secure method than something like hashing.  The argument for symmetric encryption was often around usability and speed and perhaps for password recovery style use cases - as opposed to password reset use cases if the password could not be recovered.

Password hashing is where a password is converted into a one-way set of opaque characters that visually have no relation to the clear text password - meaning hackers have a harder way of trying to get the original password.  The hash can also generally not be reversed - think of hashing like smashing a glass mirror - once smashed it's nearly impossible to get the mirror glued back together to look the same.  It's also nearly impossible to smash two identical mirrors in such a way that the broken pieces look the same.  So... hashing is seen as more secure and seen as irreversible.

But if it's do users login?  When the clear text password is entered, the password has the specific hashing algorithm applied to it and then compared to the existing hash that is stored. So we're performing a hash comparison not a clear text comparison.  I digress.

Back to OpenDJ.  OpenDJ provides a range of these different hashing algorithms out of the box. Take a look at the password storage schemes via the dsconfig interactive CLI (in ../bin/ of the main OpenDJ root folder).  Option 28 of the main menu takes you into the Password Storage Scheme area...

Most modern deployments will want to use a one way hash, generally with a salt, so something like Salted SHA512 is a nice bet.  Now the issue comes, when for example, the source data feed of users, has a hash of a lower security level than what you want in the modern world with OpenDJ.  So whilst OpenDJ supports things like SHA1 out of the box (and you can code new plugins for algorithms not supported...) you might want to migrate all users to a new more secure algorithm going forward.

Haha - the password reset scenario I mentioned above! Well not quite...OpenDJ has a neat feature that allows migration to new algorithms without getting users to reset their password.

Firstly you can set the appropriate default-password-storage-scheme to include the existing hashing algorithm (for example SSHA) when you migrate your users across.  This is done via the Password Policy option via the dsconfig main menu.  So we now have users in DJ with their password stored using the existing algorithm. A neat way to check this is the case, is to view the user via the ../bin/control-panel tool, switching to LDIF view.  Check for the userPassword attribute...and you will see the base64 encoded password.

Taking the encoded value and using something like the base64 utility that comes with most BASH distributions, you can decode the value to see the hashed value underneath.

Note the value is prefixed with the algorithm used, so it's easy to see what is happening. Next thing we can do, is to alter the default-password-storage-scheme to include our new algorithm...namely SSHA512.  Again, do this via editing the appropriate password policy.  At the same time, also alter deprecated-password-storage-scheme property include our initial algorithm - namely SSHA.

This on it's own doesn't alter the algorithm.  The change occurs, the next time the user authenticates. So logging into OpenAM with my existing user and their existing password...not only logs me also updates the password in the background to be stored using the new algorithm.

This time checking the userPassword value in the LDIF view, I can instantly see the base64 value is much longer.

Doing a base64 decode, reveals the reason: we're now storing using the SSHA512 algorithm.

A quick and simple way to upgrade algorithms without impacting the user journey.

Of course, getting the data into DJ in the first place, would be a good use case for OpenIDM through basic reconciliation using the connector framework.  It is also simple to configure OpenIDM to leverage pass through authentication to leverage the password storage schemes just configured in DJ.

For more information on password storage schemes see here.


Popular posts from this blog

WebAuthn Authentication in AM 6.5

ForgeRock AccessManagement 6.5 , will have out of the box integration for the W3C WebAuthn . This modern “FIDO2” standard allows cryptographic passwordless authentication – integrating with a range of native authenticators, from USB keys to fingerprint and facial recognition systems found natively in many mobile and desktop operating systems. Why is this so cool? Well firstly we know passwords are insecure and deliver a poor user experience. But aren’t there loads of strong MFA solutions out there already? Well, there are, but many are proprietary, require complex integrations and SDK’s and ultimately, don’t provide the level of agility that many CISO’s and application designers now require.  Rolling out a secure authentication system today, will probably only result in further integration costs and headaches tomorrow, when the next “cool” login method emerges. Having a standards based approach, allows for easier inter-operability and a more agile platform for chan

Implementing Zero Trust & CARTA within AM 6.x

There is an increasing focus on perimeterless approaches to security design and the buzzy "defensive security architectures".  This blog will take a brief look at implementing a contextual and continuous approach to access management, that can help to fulfil those design aspirations. The main concept, is to basically collect some sort of contextual data at login time, and again at resource access time - and basically look for differences between the two.  But why is this remotely interesting?  Firstly, big walls, don't necessarily mean safer houses.  The classic firewall approach to security.  Keeping the bad out and the good in.  That concept no longer works for the large modern enterprise.  The good and bad are everywhere and access control decisions should really be based on data above and beyond that directly related to the user identity, with enforcement as close as possible to the protected resource as possible. With Intelligent AuthX, we can start to collect an

Set Session Limits Using Context

Session limits typically cover 4 main items: total number of sessions a user can have at any one time, the max length of each session, the max idle time and max caching time. In an out of the box deployment in ForgeRock AM, these settings are configured via the session service.  However there are few tweaks than can be made to allow these settings to be run via a per user or per tree flow.  For example. think of the following scenario - user is logging via a device, location or network that has a higher risk rating.   Perhaps you would like to reduce session length on a BYOD device running an out of support version of Android to have a length of only 15 minutes.  If they switched back to their main trusted device, we can spin that back to 1hr. Another example, could be the spotting of a higher suspicion of bot activity for a particular user.  Maybe we need to set the entire quota limit to 1, to stop a bot spawning multiple sessions with the same credentials. This is all pretty trivial