I imagine the question would be if this is successful or not -- i.e., if you have a userPassword -> pwdHistory value with high characters and attempt to reuse it later, does this allow the password to be improperly reused? If you've got some data where this is happening and can run that experiment, that'd be a good data point.

On Mon, 3 Dec 2007, Scott Classen wrote:

I'm not sure if this is truly a vulnerability, but I thought I'd put it out there for discussion.

openldap 2.4.6 bdb backend ppolicy overlay

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}wAuvjfMkMyKKHcMV1Tg7qiG0x4

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?

Scott

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