...
What exactly is that PKCS5S2 format JIRA uses for password hashes?
'PKCS5S2' refers to "PKCS #5: Password-Based Cryptography Specification Version 2.0", a document available in RFC form which provides "recommendations for the implementation of password-based cryptography" . The recommendations include the use of the PBKDF2 'key derivation function', of which HMAC-SHA-1 is an example. Apparently.
Anyhow, the format is succinctly explained in the passlib.hash.atlassian_pbkdf2_sha1 Python library's docs:
- generates a random 16-byte salt
- feeds the salt plus password into our PBKDF2 function, which applies a hash (HMAC-SHA1) 10,000 times, yielding a a 32-byte hash
- concatenates salt and hash, and base64-encodes them
(This Python library can be used from the command-line - see Resetting a user password in the database)
. If you have a commercial Jira license, you can also download the source at https://my.atlassian.com and take a look (unpack dependencySources/atlassian-password-encoder-*-sources.jar and look at DefaultPasswordEncoder and and PKCS5S2PasswordHashGenerator
...
). Passwords are encoded bywhich:
...
...
So, easy enough. Let's unpack our sample password:
...
| Code Block |
|---|
$ salt="$(echo -n "$credential" | base64 -d | head -c16)" $ hash="$(echo -n "$credential" | base64 -d | tail -c32)" |
OpenLDAP's
OpenLDAP supports PBKDF2. The problem is that its format is different:
{PBKDF2}<Iteration>$<Adapted Base64 Salt>$<Adapted Base64 DK
We know the iteration count (10000). We know the salt, and we know the hash (derived key). We just need to reorder the elements.
"Adapted Base64" is, per the passlib docs,https://github.com/hamano/openldap-pbkdf2