11:20 a.m.
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
1:34 p.m.
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.
4:39 a.m.
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(a)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.
7:01 a.m.
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(a)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.
>
--
Dan White
2674
days inactive
2675
days old
openldap-technical@openldap.org
3 comments
3 participants
participants (3)
-
Dan White -
Rich Alford -
Ryan Tandy