My friend and fellow FreeBSD enthusiast Derek Marcotte recently pointed out that FreeBSD has no easy way to set the logarithmic rounds for bcrypt password hashes. Doing so is trivial in OpenBSD, and considering the capabilities of current GPU attacks, I want this functionality. This issue was raised over eight years ago in kern/75934 by Steven Alexander Jr., who included a patch to add this feature. Unfortunately, this seems to have been completely overlooked, and there were no public responses to this PR. I commissioned Derek to come up with a solution by either updating Steven's patch or by devising a new method. To paraphrase Derek's comments: -----BEGIN PARAPHRASIS----- I did some research into what other *BSDs are doing. OpenBSD and NetBSD use the algorithm name, a comma, and then the number of rounds: http://www.openbsd.org/cgi-bin/man.cgi?query=login.conf&sektion=5 localcipher=blowfish,6 http://netbsd.gw.com/cgi-bin/man-cgi?passwd.conf+5+NetBSD-current localcipher=blowfish,6 To me, this isn't a good way to do it because we'd need special rules to parse this extra field out of the previously unstructured data. This parsing would be algorithm dependent. Everyone knows about modular crypt, so why not feed the modular crypt salt string as the parameter directly? Instead of messing with different names, give the power to the system admin to control this directly, so when crypt is updated, pam_unix can take advantage. Each implementation of crypt algorithms already includes parsing of the salt magic. I found that patching pam_unix was the least invasive way to handle configurable hashes for login. I've added a passwd_modular parameter that will supersede passwd_format when defined. passwd_modular will feed directly into crypt, so any options that are passed to crypt via the salt are immediately available for use in the master.passwd file. For example: :passwd_modular=$2a$11$:\ Now you can also set the rounds for sha512: :passwd_modular=$6$rounds=1000000$:\ To disable passwd_modular and revert to passwd_format: :passwd_modular=disabled:\ This also lets admins shoot themselves in the foot by supplying invalid or bad salts. For example: :passwd_modular=$1$constantsalt:\ I had considered setting a second variable like ":passwd_param=8:\", but then you really have to mess with crypt to make it work. I think it would be a much more invasive change, and unnecessary, providing the documentation for login.conf is brought up to date. FreeBSD 8.* doesn't have access to the SHA family of hashes. If this is merged back into 8, it will give much stronger password security when using $2a$08$ (or higher) than is currently available. bcrypt is preferable to sha512 because of its resilience to current GPU attacks. This is expected to change. Hopefully, my patch will lay some groundwork to incorporate scrypt. -----END PARAPHRASIS----- Fix: I've attached a copy of Derek's patches for FreeBSD 10.0-CURRENT. I also have his patches for 9-STABLE, but have not included them here. I really like Derek's solution. In my opinion, committing Derek's patches will allow kern/75934 to be closed. Patch attached with submission follows:
Responsible Changed From-To: freebsd-bugs->secteam Take.
Any update on this? The original issue is now nearing 9 years old :-)
Created attachment 152839 [details] Patch against -CURRENT 201502 with a ton of enhancements, see -security does a few things with the base system: 1. allows modular crypt to be specified as passwd_format in /etc/login.conf - this allows setting the algorithm *and rounds*, i.e. $2b$10$ for users of varying classes. - this will allow any future algorithms and parameters supported by crypt(3) to be supported by the tools around login.conf 2. introduces a new api, crypt_makesalt which will generate an appropriate salt for any algorithm selected 3. updates userland to use this API, and removes totally the {crypt_set_format, login_setcryptfmt, login_getcryptfmt} APIs 4. switches crypt algorithms to use thread-local storage, so the good old global crypt buffer is thread-local 5. includes a bunch of new test vectors for libcrypt ATF tests
Created attachment 154251 [details] Patch against -CURRENT revision 279936 (20150312) with changes discussed on -security.
Created attachment 154265 [details] Updated patch against -CURRENT revision 279936 (20150312) with changes discussed on -security. Forgot to add some documentation items. They are included here. The items specifically mentioned on -security were: 3. updates userland to use this API, and removes totally the {crypt_set_format, login_setcryptfmt, login_getcryptfmt} APIs 4. switches crypt algorithms to use thread-local storage, so the good old global crypt buffer is thread-local #4 has be backed out. #3 - we've kept the old APIs and updated their documentation.
As discussed at BSDCan, submitted is going to refresh this patch
Created attachment 173187 [details] Refreshed patch, against git/a8ff864 (20160730) To recap, this patch contains: - updated libcrypt, which includes crypt_makesalt - revised/rewritten crypt(3) manpage, detailing the uses of Modular Crypt Formats, and new crypt_makesalt api - numerous test vectors for libcrypt - refactored pam_unix to use crypt_makesalt, instead of its own format - refactored pw to support Modular Crypt Formats in login.conf This will (hopefully!) lay the groundwork for a login.conf tunable to allow pam_unix to "upgrade" hashes on login to a suitable algorithm. Again, the same discussion/review that took place on -security is still relevant, this simply brings the patch up to date.
Created attachment 173188 [details] correct crypt_makesalt return code documentation Same as 173187: Refreshed patch, against git/a8ff864 (20160730), but corrected return code documentation for crypt_makesalt.
I plan to have a look at this with folks attending BSDCam during the 1st week of August.
That's great news. Happy to iterate on this, if the feedback loop is shorter.
It has been some years now, and it looks like we are still without a workable solution. Any update?
Reset status (In-Progress -> Open) on issues without a real assignee
Reset assignee (5 years since assignment). This issue doesn't strictly need to be lead/committed by secteam, and has likely gated progress due to it appearing 'taken'. It will probably need to be at least reviewed if not approved by them however, so keep them CC'd. It would be good to get the changes updated to patch/apply against CURRENT (12.0 today)
I'm still here. I'll be at BSDCan again this year. Happy to iterate, but not in isolation. Looking for someone in the project to help see this through so I'm not writing aimless patches. Thanks
(In reply to Derek from comment #14) I will also be at BSDCan. Let's see if we can get this *committed* at BSDCan. I will help you find the right people to make this happen.
FYI - this is in phabricator now: https://reviews.freebsd.org/D15713
Just checking in on this as the review went up just about a month ago.
Any progress?
If this is going nowhere, at the very least the hardcoded iteration counts should be reviewed. 5000 iterations of SHA512 and 2^4 of blowfish are hardly reasonable.