Feature #12855
closed
GUI option to select the user password hashing algorithm
100%
Description
Different scenarios may call for different types of password hashing so it makes sense to give users the choice rather than only having a single default method.
We should offer a choice between at least the following hashes:
- bcrypt (Default) for higher security
- SHA-512 with the default number of rounds for compatibility/compliance/performance
Though we could offer a higher number of rounds with SHA512, the number of rounds must be identical when hashing and checking the hash so it is not compatible with hashes made with the default number of rounds. There could maybe be a separate/isolated "high rounds" SHA-512 option but that may be more confusing as it would require treating it as a completely separate hash type with its own uniquely named tag and so on.
We already have code in place to check these hash types, so the necessary changes should be fairly simple:
- Add a UI element to pick the hash type on
system_usermanager_settings.php - Add code to check the value of this setting before creating a hash of a user password
- Ensure the code cleans up other hash types when making a new hash
Related issues
Updated by Jim Pingle almost 3 years ago
- Related to Todo #10298: Use SHA-512 for user password hashes added
- Related to Bug #12800: Suboptimal Password Hashing added
Updated by Royce Williams almost 3 years ago
Jim Pingle wrote:
Though we could offer a higher number of rounds with SHA512, the number of rounds must be identical when hashing and checking the hash so it is not compatible with hashes made with the default number of rounds.
For what it's worth, both bcrypt and sha512crypt are designed to expect their variable work factors to be programmatically available to, and detected and used by, the authentication layer - for work factors to not be hard-coded on the authentication side (other than as default values at hash creation time only).
In other words, a given set of hashes should be able to contain an arbitrary mix of rounds, which are then automatically used as part of hash validation on a hash-by-hash basis. This allows for transparent forward and backward compatibility over time.
For example, if future hardware speeds make it attractive to change the bcrypt default from 10 to 12, then when all new hashes can be created with cost 12, all legacy cost 10 bcrypt hashes should also continue to Just Work.
Edit: interested readers may not be aware that sha512crypt has a "silent" default of 5000 rounds, and only when that value is overridden does the number of rounds explicitly appear in the hash:
$ mkpasswd -m SHA-512 -S $(tr -dc '[:alnum:]./' < /dev/urandom | fold -w ${1:-16} | head -n 1)
Password:
$6$5XxpqcgR.YyEC9mk$9oeQAUShRn7ZhnmlOGihguD0QI5Mi2wvm5bs1RpfFteMCPoDSQ/vEBsES0hfoV9anwn3SAVEsT97Ha84L7g2v/
$ mkpasswd -m SHA-512 -S $(tr -dc '[:alnum:]./' < /dev/urandom | fold -w ${1:-16} | head -n 1) -R 5000
Password:
$6$rounds=5000$6R37T0WdXN3MC3Hd$T9Ze7R6ZZHuw9WGNTM838.LmJOUpZ1kTCifMk0AGNqnDzQSEEqRWWt/8vr5mWgS2ZP7HyvRZ/D6JLFr1Ck6l4/
$ mkpasswd -m SHA-512 -S $(tr -dc '[:alnum:]./' < /dev/urandom | fold -w ${1:-16} | head -n 1) -R 800000
Password:
$6$rounds=800000$GAuO13spo1MJYChS$jtB8CbJu2vKIwIljcDP/YLKKII5r6jhX/9kJrZbmPrsFDG0.D8IETRUIvaf9KEp7H91yj/vOG3tBKLtw2QO/z.
Updated by Jim Pingle almost 3 years ago
- Status changed from In Progress to Pull Request Review
Internal MR for initial testing/review: https://gitlab.netgate.com/pfSense/pfSense/-/merge_requests/636
Updated by Jim Pingle almost 3 years ago
- Status changed from Pull Request Review to Feedback
- % Done changed from 0 to 100
Applied in changeset 8ddf2b5a999772754080825f07acf9b6326f1f04.
Updated by Jim Pingle almost 3 years ago
This has been merged and will be in snapshots soon.
For those who would like to try it out, even on 22.01/2.6.0, install the System Patches package and then create entries for 961f240c18f8421b0a28ee192ffa041e754e8f8e and then 8ddf2b5a999772754080825f07acf9b6326f1f04 to apply the fix.
Apply 961f240c18f8421b0a28ee192ffa041e754e8f8e first followed by 8ddf2b5a999772754080825f07acf9b6326f1f04
Updated by Jim Pingle almost 3 years ago
- Status changed from Feedback to Resolved
This is working well. I've also added it as a recommended patch option in the new system patches package, so people on 22.01 and 2.6.0 have an easy way to obtain the change without waiting for the next release or adding a patch entry by hand.
Updated by Jim Pingle over 2 years ago
- Subject changed from Allow the user to choose password hashing method to GUI option to select the user password hashing algorithm
Updating subject for release notes.