#48947 RFE: DEFAULT password mechanism
Closed: wontfix None Opened 4 years ago by firstyear.

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:


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.

We may not need this. By default in libglobs.c, we set a hash value and type in the #define. If the attr password-storage-scheme is deleted, this is reset to the default. However, to allow this running, we need to fix the same issue as https://fedorahosted.org/389/ticket/48961, if we want to allow a "running" reset to default.

commit 524c0ca
Compressing objects: 100% (10/10), done.
Writing objects: 100% (10/10), 3.00 KiB | 0 bytes/s, done.
Total 10 (delta 8), reused 0 (delta 0)
To ssh://git.fedorahosted.org/git/389/ds.git
68a7640..524c0ca master -> master

Metadata Update from @firstyear:
- Issue assigned to firstyear
- Issue set to the milestone:

4 years ago

389-ds-base is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in 389-ds-base's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/389ds/389-ds-base/issues/2006

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.

Metadata Update from @spichugi:
- Issue close_status updated to: wontfix (was: Fixed)

7 months ago

Login to comment on this ticket.