Hi!
Examining changes of the database via LDIF, I noticed one thing: -userPassword: {SSHA}XY94+nfFELR3iy0AYTsS0DHqxIOwFNz79zcnniA== +userPassword: {SSHA}yt98Od1WHak3kYIyZWYoCewg4D+f9ffp
I had thought that the encoded SSHA passwords all have the same length. Could it depend on the program being used to vhnage the password, thus varying the length of salt? How could I decode that? (not that the example is not a real one (some characters permutated), so don't waste your time trying to crack it)
Regards, Ulrich
--On Monday, December 5, 2022 8:02 AM +0100 Ulrich Windl Ulrich.Windl@rz.uni-regensburg.de wrote:
Hi!
Examining changes of the database via LDIF, I noticed one thing: -userPassword: {SSHA}XY94+nfFELR3iy0AYTsS0DHqxIOwFNz79zcnniA== +userPassword: {SSHA}yt98Od1WHak3kYIyZWYoCewg4D+f9ffp
I had thought that the encoded SSHA passwords all have the same length. Could it depend on the program being used to vhnage the password, thus varying the length of salt? How could I decode that? (not that the example is not a real one (some characters permutated), so don't waste your time trying to crack it)
Hi Ulrich,
The first SSHA hash looks like it was created by something other than OpenLDAP via an ldap password v3 modifiation. Do you have processes doing direct modifications to the userPassword attribute? Or, are you sure that in the first case, it wasn't:
userPassword:: <HEX>
vs
userPassword: {SSHA}<value>
?
In either case, SSHA is not particularly secure I'd strongly advise ensuring that:
a) slapd does the password hashing b) slapd is updated to use a strong hashing method
Regards, Quanah
On Mon, Dec 05, 2022 at 08:02:22 +0100, Ulrich Windl wrote:
I had thought that the encoded SSHA passwords all have the same length. Could it depend on the program being used to change the password, thus varying the length of salt?
Yes, the salt can be of arbitrary length.
How could I decode that?
The first 160 bits (after base64 decoding) are the SHA1 hash, the remaining part is the salt.
Geert
openldap-technical@openldap.org