[Date Prev][Date Next]
RE: ppolicy + slapcat = ldif vulnerability?
>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
>but the passwd history leaves the passwd hashes visible.
>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
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?