Timeline for What is the specific reason to prefer bcrypt or PBKDF2 over SHA256-crypt in password hashes?
Current License: CC BY-SA 3.0
12 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Mar 17, 2017 at 13:14 | history | edited | CommunityBot |
replaced http://security.stackexchange.com/ with https://security.stackexchange.com/
|
|
| Aug 15, 2016 at 12:21 | history | edited | 700 Software | CC BY-SA 3.0 |
added 16 characters in body
|
| Aug 11, 2016 at 19:14 | comment | added | 700 Software | Part of your question "Is there some reason not to use them" relates very much to how well it was implemented. SHA-256 was not designed to be a 'password hash', so language-specific libraries may not be as seriously compelled to implement it in native C. This also makes installs easier for certain users who do not have the right compilers set up. Also it's tempting for a developer to write their own iteration for rounds. I like to include implementation details in an answer to prevent future visitors from jumping to a conclusion. | |
| Aug 11, 2016 at 15:43 | comment | added | ilkkachu |
I think implementation details are a bit of a different question than the question of the relative merits of the algorithms, and they would be system-dependant too. e.g. on OpenBSD you'd be very likely to have $2y$ supported by the system's libc, but not so on all Linuxes. As for the libraries of popular programming languages, I hope they'd have C implementations of any (password) hashes they support, but I can't be sure without checking.
|
|
| Aug 9, 2016 at 12:39 | history | edited | 700 Software | CC BY-SA 3.0 |
deleted 46 characters in body
|
| Aug 9, 2016 at 12:14 | comment | added | Thomas Pornin | It must be noted that scrypt uses a configurable amount of memory that depends on how fast it must complete. If you use scrypt on a busy authentication server and must compute a password hash within less than 5 ms or so, then scrypt cannot use much RAM and turns out to be less GPU-resistant than bcrypt. Scrypt was really meant for hard disk encryption (so 1 to 5 seconds computation time); it is not necessarily appropriate for all other situations. This is in fact what prompted the Password Hashing Competition. | |
| Aug 9, 2016 at 9:28 | history | edited | SilverlightFox | CC BY-SA 3.0 |
added 63 characters in body
|
| Aug 8, 2016 at 23:11 | history | edited | 700 Software | CC BY-SA 3.0 |
added 16 characters in body
|
| Aug 8, 2016 at 21:35 | history | edited | 700 Software | CC BY-SA 3.0 |
added 84 characters in body
|
| Aug 8, 2016 at 18:21 | history | edited | 700 Software | CC BY-SA 3.0 |
added 104 characters in body
|
| Aug 8, 2016 at 14:56 | history | edited | 700 Software | CC BY-SA 3.0 |
added 22 characters in body
|
| Aug 8, 2016 at 14:50 | history | answered | 700 Software | CC BY-SA 3.0 |