Hi All:
I'm not sure if this issue results from my ignorance of OpenLdap, or it's not capable of resolving. Regardless, any direction you can provide would be greatly appreciated:
I have a basic OpenLdap installation with TLS encryption. Passwords are hashed in the ldap directory. The user password travels from client to server encrypted as it should, then gets unencrypted by slapd, and IF IN DEBUG MODE gets displayed in *clear-text*. Theoretically, the password should be hashed on the client, sent across the network, to be compared against the hashed passwords in the database.
What am I missing??
Thank you, Rich
On Mon, Nov 30, 2015 at 02:20:44PM -0500, Rich Alford wrote:
Theoretically, the password should be hashed on the client, sent across the network, to be compared against the hashed passwords in the database.
The client has no idea how the server stores or hashes passwords. The server might not even store them directly, but could be passing them to a third party (f.ex. a Kerberos KDC) for verification. So the client sends the password to the server in the clear (but protected by TLS), and the server verifies the password however it's configured to, in your case by hashing it and comparing the hash to the stored hash.
Thank you Ryan. So there's no way around that? I.e. Is there a strategy that can alleviate that?
On Mon, Nov 30, 2015 at 4:34 PM, Ryan Tandy ryan@nardis.ca wrote:
On Mon, Nov 30, 2015 at 02:20:44PM -0500, Rich Alford wrote:
Theoretically, the password should be hashed on the client, sent across the network, to be compared against the hashed passwords in the database.
The client has no idea how the server stores or hashes passwords. The server might not even store them directly, but could be passing them to a third party (f.ex. a Kerberos KDC) for verification. So the client sends the password to the server in the clear (but protected by TLS), and the server verifies the password however it's configured to, in your case by hashing it and comparing the hash to the stored hash.
Two approaches are Kerberos and SASL EXTERNAL authentication over client TLS certificates. Neither approach reveals private key material to the server.
On 12/01/15 07:39 -0500, Rich Alford wrote:
Thank you Ryan. So there's no way around that? I.e. Is there a strategy that can alleviate that?
On Mon, Nov 30, 2015 at 4:34 PM, Ryan Tandy ryan@nardis.ca wrote:
On Mon, Nov 30, 2015 at 02:20:44PM -0500, Rich Alford wrote:
Theoretically, the password should be hashed on the client, sent across the network, to be compared against the hashed passwords in the database.
The client has no idea how the server stores or hashes passwords. The server might not even store them directly, but could be passing them to a third party (f.ex. a Kerberos KDC) for verification. So the client sends the password to the server in the clear (but protected by TLS), and the server verifies the password however it's configured to, in your case by hashing it and comparing the hash to the stored hash.
openldap-technical@openldap.org
-
Dan White -
Rich Alford -
Ryan Tandy