glibc has a pretty nice function called crypt_r(3), which is nothing
more than crypt(3), but thread-safe. It accomplishes this by introducing
a 'struct crypt_data' structure that contains a buffer that is large
enough to hold the resulting string.
Let's go ahead and also add this function. It would be a shame if a
useful function like this wouldn't be usable in multithreaded apps.
Refactor crypt.c and all of the backends to no longer declare static
arrays, but write their output in a provided buffer.
There is no need to do any buffer length computation here, as we'll just
need to ensure that 'struct crypt_data' is large enough, which it is.
_PASSWORD_LEN is defined to 128 bytes, but in this case I'm picking 256,
as this is going to be part of the actual ABI.
Differential Revision: https://reviews.freebsd.org/D7306
crypt_blowfish and many implementations based on it (Apache, PHP, PostgreSQL) implemented $2y$ before OpenBSD went with $2b$. This changes marks them as equivalent.
http://www.openwall.com/lists/announce/2011/07/17/1
This change is required for applications that use the base crypt() implementation (including nginx) to be able to validate $2y$ hashes
Reviewed by: eadler
Approved by: delphij
MFC after: 1 week
Relnotes: yes
Sponsored by: ScaleEngine Inc.
Differential Revision: https://reviews.freebsd.org/D2742
Notable changes:
- Support of $2b$ password format to address a problem where very
long passwords (more than 256 characters, when an integer
overflow would happen and cause the length to wrap at 256).
- Updated pseudo code in comments to reflect the reality.
- Removed our local shortcut of processing magic string and rely
on the centralized and tigntened validation.
- Diff reduction from upstream.
For now we are still generating the older $02a$ format of password
but we will migrate to the new format once the format is formally
finalized.
MFC after: 1 month
gratuitous difference between us and our sister project.
This was given to me _ages_ ago. May apologies to Paul for the length
of time its taken me to commit.
Obtained from: Niels Provos <provos@physnet.uni-hamburg.de>/OpenBSD
Submitted by: Paul Herman <pherman@frenchfries.net>
