[SERVER-2360] Add a stronger password authentication scheme (replace md5 with sha?) Created: 14/Jan/11 Updated: 12/Jul/16 Resolved: 12/Sep/14 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Security |
| Affects Version/s: | None |
| Fix Version/s: | 2.7.7 |
| Type: | New Feature | Priority: | Minor - P4 |
| Reporter: | Daniel Doubrovkine | Assignee: | Andreas Nilsson |
| Resolution: | Done | Votes: | 6 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||||||||||||||
| Participants: | |||||||||||||||||||||||||||||
| Description |
|
Add a stronger authentication scheme, ideally something certificate-based. The current protocol for password authentication using Md5 looks reversible via rainbow (not confirmed). |
| Comments |
| Comment by Jan Paul Ettles [ 07/Feb/13 ] |
|
I agree with Tim ^ md5 and sha1 are designed to be quick, which is just what many cracking methods rely upon and as such should be avoided. My 2p worth: A minimum length should be imposed to increase entropy. |
| Comment by Dave Curylo [ 17/Dec/12 ] |
|
David - regarding Keccak, this is a case where "leading edge" and "compliance" don't go hand in hand. This algorithm is so new that I don't know that there are any implementations that have been certified as compliant. Daniel - yes, indeed, the server needs to use an implementation that has been FIPS certified, like those in the OpenSSL libraries. Drivers also need to be able to use a FIPS compliant algorithm. On Windows, for example, the .NET driver complies with the OS settings for FIPS compliance and will disable non-compliant algorithms, which aids in proving certification. |
| Comment by Daniel Doubrovkine [ 17/Dec/12 ] |
|
I've dealt with US govt and FIPS for many years. This is not just about the algorithm, even if you use one of the algos used on that list, you still need to prove that you're actually using the correct implementation, so the entire encryption infrastructure to be FIPS-certified. If you're going to use OpenSSL, read http://www.openssl.org/docs/fips/fipsnotes.html, and find a way to selectively compile with the OpenSSL FIPS Object Module. |
| Comment by David Hows [ 16/Dec/12 ] |
|
davec while its not listed, do you know if SHA-3 (Keccak) would be suitable? The algorithm was selected in October when the testing finished and I can't tell if it has made it to the list of approved algo's in the toolkit you linked. |
| Comment by Dave Curylo [ 16/Dec/12 ] |
|
Whatever is chosen, please ensure it falls on the list of FIPS-140 compliant algorithms. This is crucial for many federal government projects. HMAC+SHA256 would be great. PBKDF2 on top of that, even better. BCRYPT, while excellent, is not FIPS compliant. From my comments in (related duplicate) |
| Comment by Tim [ 16/Dec/12 ] |
|
I would suggest bcrypt over sha, since bcrypt is much slower than sha and that is exactly what you want in a password hashing scheme. Above that it's also adaptive, which plain sha is not. See http://stackoverflow.com/questions/1561174/sha512-vs-blowfish-and-bcrypt and the links i gave above. |
| Comment by Tim [ 20/Jun/12 ] |
|
Actually, neither MD5 nor SHA1 are safe these days. Even with salts, attacks are only a matter of seconds with any random 7 character password and some generic GPU hardware. The current hashes are easily reversed once in bad hands. And although the data won't be protected by it, it would be nice if the used password should not be reversibele and leak. References: edit: |
| Comment by Dwight Merriman [ 22/Jun/11 ] |
|
a min pwd length would be good too |
| Comment by Dwight Merriman [ 22/Jun/11 ] |
|
the digests are salted, so rainbow should not work well. this does bring to mind one improvement: system.users pwd field should be made unreadable, for non-admins at a minimum, before this ticket is closed. i think the cleanest way is to simply make that ns not queryable period by non-admins otherwise it is a bit trickier to implement. |
| Comment by Daniel Doubrovkine [ 14/Jan/11 ] |
|
Note that maybe with an SSL implementation with |