Emmanuel Lecharny wrote:
is it the server responsability to compare the user's password against
an encrypted form or should the client encrypt the password before
sending it to the server ?
I mean, we can have one of those two possibilities :
1) [client] --(clear password)--> <network> --> [server] --> encrypt the
password and compares it to the stored encrypted password
or
2) [client] --(encrypt password)--> <network> [server] --> compares the
encrypted password and compares it to the stored encrypted password
...
PS : we have solution 1 currently implemented. Is it correct ?
Hi Emmanuel!
Option 1 is currently implemented. The client can not authenticate via
simple bind with the encrypted (digested) value. S/he must send the
password in clear (ideally via ldaps). See here:
http://directory.apache.org/apacheds/1.0/31-authentication-options.html
Cite:
--8<--
Providing the hashed value of the userpassword attribute instead of the
original value will be rejected by ApacheDS:
$ ldapsearch -h zanzibar -p 10389 -D "cn=Horatio
Hornblower,ou=people,o=sevenSeas" \\
-w "{SHA}nU4eI71bcnBGqeO0t9tXvY1u5oQ=" -b "ou=people,o=sevenSeas"
-s base "(objectclass=*)"
ldap_simple_bind: Invalid credentials
ldap_simple_bind: additional info: Bind failed: null
This is intended. If someone was able to catch this value (from an LDIF
export for instance), s/he must still provide the password itself in
order to get authenticated.
-->8--
This is why I think option 2 is not recommended at all. By the way: the
following servers behave exactly the same:
* OpenLDAP 2.3
* Sun Java System Directory Server 5.2
* IBM Tivoli Directory Server 6.0
Greetings,
Stefan
