We should add a new value to passwordStorageScheme of DEFAULT. This would use the "current strongest" hashing mechanism for passwords that is available. The decision of what hashing mechanism would be made by our team, and re-evaluated on a regular basis.

For a majority of DS deployments, they want something that "just works". They may not currently be changing their passwordStorageScheme from SSHA to SSHA512. As a result, they are not gaining the advantages, and this exposes greater risk to their users and their business.

Because of this change, sites that already have a policy and requirements around what hashing mechanisms they use, they could continue to do so. This only benefits new installations, and their subsequent upgrades.

A key value of this proposal is that we could upgrade the DEFAULT type between versions. Because of how password hashes are stored, they have the format:

{SSHA}.....

Existing passwords would still work, even on a version upgrade, as during a pwd_cmp, we read the value from the DB, and determine the hash mechanism to use based on that prefix. So if DEFAULT were to be SSHA512, existing {SSHA} would still function.

When the user changes their password next their hash would be upgraded to the new DEFAULT, without any administrator intervention or change.

Part of #48876 would allow on a successful simple bind, if the current on disk hash format doesn't match the passwordStorageScheme type, we would be able to upgrade the hash mechanism in place as part of the bind process. This means on DS upgrade, sites would see a much faster adoption of stronger hashes.

A concern is administrators wanting to know what the current in use mechanism is, so this is key that we add a way for the admin to see and resolve what DEFAULT means in this version of DS.

Values for the DEFAULT hash type, must be in pwdstorage modules, and they must have been in DS for some X number of versions. This way, when a set of servers is upgraded, all nodes already support the hash mechanism, and we effectively "flick the switch" on for the upgrade. Consider we add SCRYPT to DS. If we didn't delay, and just made it the DEFAULT, when a site upgrades their servers A and B, A would suddenly have SCRYPT, and would upgrade hashes. B would receive the replicated hashes, and would be unable to service bind requests.

The greatest benefit to this change, is reduced Administrator overhead of password storage and a concrete increase in password storage security during upgrades.