I'm not sure if this is truly a vulnerability, but I thought I'd put it
out there for discussion.
I have set up so a default ppolicy such that 3 old passwords are stored
in a users pwdHistory attribute.
When I back up the bdb database via slapcat -l backup.ldif the
userPassword field looks to be Base64
hashed.
userPassword:: e1NTSEF9VWFTNDNVDRWEx1QzEyWjASGVWc0VZHRNTmt4M1c=
but the passwd history leaves the passwd hashes visible.
pwdHistory:
20071203220105Z#1.3.6.1.4.1.1466.115.121.1.40#38#{SSHA}wAuvjfMkMyKKHcMV1 Tg7qiG0x4
Obviously these backup LDIF files are keep as secure as possible, and
these are OLD passwds, but
should the pwdHistory attribute also be hashed when being slapcated?
Keep in mind that base 64 encoded hashing is NOT any form of encryption - i.e. it's reversible, and you don't have to "know" anything secret to decode it, so the fact that one is base64 hashed and one is not really provides no true security benefit (other than very minimal obscuring so that you can't see passwords at a quick glance) and doesn't create any real security hole. The main reason for base64 encoding attributes in LDAP, as far as I've ever heard, is just to ensure binary values are 7 bit ascii text file safe for import/export. Base64 is definitely not something to consider as a security mechanism. The ssha hash is what "protects" the password (i.e. it IS encryption). You want to prevent people from seeing that hash (i.e. acl's to prevent seeing it via LDAP lookups, secure the slapcat output, etc) because it is possible to come up with a valid password using the ssha hash (brute forcing it offline, or I'm sure there are huge precomputed db's of ssha hashes out there, etc), but the base64 encoding itself is a minimum to none barrier to any of this.
My biggest question would be why these 2 attributes are treated differently - i.e. are userpassword and pwdhistory different types or something to trigger different behaviour, or does slapcat just hardcode userpassword as an attribute to base64 hash, etc?
- Jeff