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:
- chosen appropriate SASL mechanism names. Should we prefix with "X-"? Suggested name "X-SSHA-512-SCRAM-SHA-512"
- implement SASL client/server mechanisms for common migration use cases. I envisage only needing SSHA-512 -> SCRAM-512 or SCRAM-256
- added server side lazy migration of user credentials, e.g. via a pre-op plugin.