[OPENDJ-6736] Support migration from SSHA-256/512 password storage schemes to SCRAM-SHA-256/512 Created: 25/Oct/19  Updated: 28/Jul/20

Status: Dev backlog
Project: OpenDJ
Component/s: core apis, security
Affects Version/s: 7.0.0
Fix Version/s: None

Type: New Feature Priority: Critical
Reporter: Matthew Swift Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: 7.0-at-risk

Story Points: 3
Dev Assignee: Matthew Swift


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:

     SaltedPassword  := Hi(Normalize(password), salt, i)

The modified mechanisms instead define it as this:

     HashedPassword  := H(password + salt)
     SaltedPassword  := Hi(HashedPassword, salt, i)

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.

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:

  • PBKDF2WithHmacSHA512 -> SCRAM-SHA-512
  • PBKDF2WithHmacSHA256 -> SCRAM-SHA-256
  • PBKDF2 -> SCRAM-SHA-1 (although we won't support this).
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:

// Perform any remaining processing for a successful simple authentication.

Note that this processing is not performed for any SASL mechanisms, including SASL PLAIN.

Generated at Fri Oct 23 08:34:30 UTC 2020 using Jira 7.13.12#713012-sha1:6e07c38070d5191bbf7353952ed38f111754533a.