Apache Directory Project - Simple bind, if user's password is stored one-way encrypted (DIREVE-296)

This is Interesting: Free IT Magazines  
Home > Archive > Apache Directory Project > November 2005 > Simple bind, if user's password is stored one-way encrypted (DIREVE-296)





You are viewing an archived Text-only version of the thread. To view this thread in it's original format and/or if you want to reply to this thread please [click here]

Author Simple bind, if user's password is stored one-way encrypted (DIREVE-296)
Stefan Zoerner

2005-11-22, 5:45 pm

Hi all!

In order to start the implementation of DIREVE-296 I made a minor change
to class SimpleAuthenticator in org.apache.ldap.server.authn. If a user
password is stored as a hash value, the authenticator now applies the
same algorithm to the provided password, and compares it to the stored
message digest.

The component supports all algorithms known to
java.security.MessageDigest, e.g. SHA and MD5.

Example: Create an entry like this, with a hashed password ("scarlet" in
this case, with SHA applied):

dn: cn=Tori Amos,dc=example,dc=com
sn: Amos
objectClass: person
objectClass: top
cn: Tori Amos
userPassword: {SHA}W8/gDnKpQb8xodYl5BnNeruhcgM=

Although the pwd is stored one-way encrypted, the user is still able to
bind with the password in clear:

$ ldapsearch -p 10389 -b "dc=example,dc=com" -s sub -D "cn=Tori
Amos,dc=example,dc=com" -w scarlet (sn=Amos) dn
cn=Tori Amos,dc=example,dc=com
$ ldapsearch -p 10389 -b "dc=example,dc=com" -s sub -D "cn=Tori
Amos,dc=example,dc=com" -w scarle (sn=Amos) dn
ldap_simple_bind: Invalid credentials

One advantage is that an admin user (or any other) is not able to see
the stored passwords in clear text. Further on LDIF exports do not
expose clear passwords.

*** Notes ***

(1) If passwords are stored in clear, the behavior of the class is
unaffected.

(2) Security is not significantly increased, because if one knows the
digested value, s/he may be able to find out the password with a brute
force attack (digest algorithms are both public and fast). But it is a
feature most LDAP servers support, and we made good experiences with it
in practice.

(3) The server does not automatically store passwords as hash values
(yet). We may easily achieve this by adding functionality to a new or
existing interceptor. I dream of a PasswordStorageInterceptor, which may
also perform configurable syntax checks (minimum complexity etc.), but
we may also do this after the 1.0 release ...

(4) If you wish to store a user's password as a hash, and like UI tools,
you may use one of these clients:
* Softerra LDAP Administrator
* LDAP Browser/Editor 2.8.2 (Jarek Gawor).
Both offer to calculate the hash value of the password before submission
to the server.

Suggestions for improvements are welcome.
Greetings from Hamburg,
Stefan




Sponsored Links






Free braindumps | Software forum | Database administration forum

Copyright 2003 - 2008 webservertalk.com