[OPENDJ-6736] Support migration from SSHA-256/512 password storage schemes to SCRAM-SHA-256/512 Created: 25/Oct/19 Updated: 28/Jul/20
|Component/s:||core apis, security|
Many users are currently using SSHA-512 but would like to migrate to a cost-based mechanism that pushes the cost to the client application, yet does not require them to wait for all users to have to re-authenticate or reset their all passwords.
One way to support migration would be to implement additional non-standard SCRAM mechanisms for these use cases. The mechanisms would implement a slightly modified SCRAM computation that adds an extra initial SSHA step and re-uses the existing salt. RFC 5803 defines the SaltedPassword as follows:
The modified mechanisms instead define it as this:
Note that the Normalize operation has been removed because I don't think DS is doing it currently. This approach allows us to migrate existing users because the HashPassword and salt are already stored in the user's entry. We send the salt to the client so that it can perform the extra processing step.
This issue can be closed once the following acceptance criteria are met:
|Comment by Matthew Swift [ 25/Oct/19 ]|
Neil Madden - I'd be interested in your feedback on this. I was inspired by your post about how Facebook have migrated from MD5 to Scrypt. The basic idea is to first SSHA-512 the password and then do SCRAM-SHA-256/512. We can re-use the salt from the existing hashed password.
It is transparent from the client app point of view, except that they just need to specify the non-standard SASL mechanism name instead of the standard SCRAM-SHA-xxx name.
|Comment by Matthew Swift [ 12/Nov/19 ]|
Note that the following existing storage schemes can easily be migrated to standard SCRAM mechanisms because we already have the SCRAM SaltedPassword:
|Comment by Matthew Swift [ 19/Nov/19 ]|
In order to migrate passwords to SCRAM credentials the SCRAM SASL mechanism should do something similar to password rehashing. Today this is handled when processing simple bind requests using the following sequence of calls:
Note that this processing is not performed for any SASL mechanisms, including SASL PLAIN.