Bug 204626 (pwsyntaxhashedpwds) - Password syntax checking is performed also on hashed values
Summary: Password syntax checking is performed also on hashed values
Alias: pwsyntaxhashedpwds
Product: 389
Classification: Retired
Component: Security - Password Policy
Version: 1.0.2
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Nathan Kinder
QA Contact: Chandrasekar Kannan
Depends On:
Blocks: 434915 FDS1.2.0
TreeView+ depends on / blocked
Reported: 2006-08-30 14:48 UTC by Michal Vocu
Modified: 2015-01-04 23:20 UTC (History)
4 users (show)

Fixed In Version: 8.1
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2009-04-29 22:59:06 UTC

Attachments (Terms of Use)
CVS Diffs (3.06 KB, patch)
2009-01-16 16:19 UTC, Nathan Kinder
no flags Details | Diff
Revised Diffs (3.98 KB, patch)
2009-01-16 16:30 UTC, Nathan Kinder
no flags Details | Diff

Description Michal Vocu 2006-08-30 14:48:01 UTC
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):

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 :-)

Comment 1 Rich Megginson 2006-08-30 15:42:14 UTC
Seems like the right thing to do is to disallow storing hashed values if syntax
checking is on, except for privileged users.

Comment 2 Rich Megginson 2006-10-12 20:20:10 UTC
Replication should be included among the privileged users, by default.

Comment 4 Nathan Kinder 2009-01-16 16:19:37 UTC
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.

Comment 5 Nathan Kinder 2009-01-16 16:30:53 UTC
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.

Comment 6 Nathan Kinder 2009-01-16 17:55:05 UTC
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

Comment 7 Yi Zhang 2009-04-09 22:16:16 UTC
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

6. save the user

==> result: pass.

Comment 8 Chandrasekar Kannan 2009-04-29 22:59:06 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.