Description of problem: When user sets her password using hashed value (ie. using something like "{SHA}base_64_encoded_sha1_password_hash"), that value is stored without going through another hash scheme (which is correct). However, if the password policy dictates syntax checking, the checks are performed on the base64 encoded string; this is rather pointless. Version-Release number of selected component (if applicable): 1.0.2 How reproducible: Always. Steps to Reproduce: 1. Turn on password syntax checking in password policy. 2. Set password using already hashed value. Actual results: Hashed value is checked for correct syntax. Expected results: Hashed values are not checked or storing already hashed values is not allowed. Additional info: In the current situation the password policy syntax checking can be easily circumvented by modifying userPassword using already hashed values. The base64 encoded hash value is likely to pass the checks successfully even if the original password is trivial. However storing hashed values into userPassword by client is very useful feature. I can imagine some possible behaviours: 1) storing hashed values is disabled when syntax checking is on, making the hashed value go through the appropriate pwd storage scheme hash function or simply refuse the operation, 2) storing hashed values is allowed only to privileged users, 3) syntax checking is disabled for hash values (and this is documented) I do not have strong opinion about the variants. Any user who is knowledgeable enough to prepare hash of password and stuff it to the server should deserve it :-)
Seems like the right thing to do is to disallow storing hashed values if syntax checking is on, except for privileged users.
Replication should be included among the privileged users, by default.
Created attachment 329220 [details] CVS Diffs This patch simply checks if a password is pre-hashed in the password syntax checking code. It will reject a pre-hashed password if syntax checking is enabled, with the exception of replicated operations and those initiated by the root DN.
Created attachment 329221 [details] Revised Diffs The previous diffs were still checking the password syntax of pre-hashed passwords that we allow. This adds the logic to skip the syntax check if the root DN or replication is providing a pre-hashed password.
Checked into ldapserver (HEAD). Thanks to Rich for his review! Checking in ldap/servers/slapd/pw.c; /cvs/dirsec/ldapserver/ldap/servers/slapd/pw.c,v <-- pw.c new revision: 1.21; previous revision: 1.20 done
verified, bug closed Test : 1. install DS and Console 2. set user "cn=directory manager" 's password to "redhat123", the hashed value is: {SSHA}PrcatfRQPNEmJZiquYv9ESZOvKnOvF+xQTFfNg== 3. launch console, login as "cn=directory manager" 4. setup password syntax "at least 5 digit" 5. create a user from console, set password to {SSHA}PrcatfRQPNEmJZiquYv9ESZOvKnOvF+xQTFfNg== 6. save the user ==> result: pass.
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHEA-2009-0455.html