I am implementing AM and DS migrating from a legacy web application that writes the password hashes in the PBKDF2-HMAC-256 format. I can reverse the storage / hash into a byte array from the legacy platform to get the pbkdf2 byte array, then encode it, but am trying to load this into DS to allow for migration / re-hashing on login for users so we don’t need to do password reset / pass-through auth. But, when doing this, DS is not recognizing the password. Was wondering if anyone has done this before to move this hash to DS and how to set it up in DS to tag this. The format I am writing to DS is the below.
{PBKDF2-HMAC-SHA256}10:
By way of background, this system uses a 50000k iteration count for the write to the db.
Hi @nick.hunt - the number you see after the storage scheme is the number of iterations used. For your case you’d want the value to be {PBKDF2-HMAC-SHA256}50000:BASE64-ENCODED-STRING
Yeah, tried doing that and still is not picking it up. I have a validation procedure from the previous system so think I am going to do a custom password storage scheme to be able to validate the passwords then allow the password-rehashing to the latest on login since that seems to be the best approach to get this done.
Hi
A couple of things perhaps worth mentioning here.
This password scheme is available as of Version 7.0, and it is still available in the latest version 7.3.0. You do not mention your DS version, so, that is the first check.
The number of iteration of 50K is incredibly high. NIST recommendations are much lower than that. You may want to double check that number.
Finally I am not sure the need for a custom storage scheme. If you are implementing a Just In Time (JIT) password validation you may validate a password from your legacy application and store it in DS with an out of the box scheme (i.e. hashing algorithm), which can even be PBKDF2 SHA256 with as many iterations as needed, but using 50K iterations will affect performance, you may want to review your compliance options.
You sat the password policy for the accounts with pbkdf2 sha 256 and 50k iterations before loading the passwords.
You enabled DS flag “allow storing encoded passwords “, otherwise DS will hash your hash before storing it.
Another approach to avoid writing a custom storage scheme is to use the Authentication Tree to validate the password in the legacy system for the first time login, and store it in DS when validation succeed.
Good point about the pre-encoded passwords configuration. Is the “allow pre-encoded password” parameter set? https://backstage.forgerock.com/knowledge/kb/article/a70476528#r_CaeV
It is not necessary to set the password scheme to match the hashing algorithm (PBKDF2-HMAC-SHA256) before the import. DS will use the tag in braces to identify the hashing algorithm that needs to be used.