directory-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lécharny <>
Subject Re: Hello! I have a question about apache ldap API!
Date Wed, 13 Mar 2019 08:44:29 GMT

On 13/03/2019 08:07, 이승윤(파트너) - 플랫폼담당인프라개발2팀 wrote:
> Thank you for contributing LDAP API!!

Thanks for using it !

> I have a question about connection bind!

Answer embedded. Note that I'm stressing out some very basic points you 
may perfectly know, but as this is a public mailing list, that may 
clarify things for other users too, so please don't feel like this is a 
lecture, it's not...

> Simple bind
> The most common bind uses an identifier and a password. The identifier must be a DN,
and the password can be encrypted. Here is an example of a bind operation :
> // Don't do that ! Password in clear text = danger !
> connection.bind( "ou=example, dc=com", "secret" );

No. There is *nothing* wrong passing a password as a String to a remote 
server, assuming the communication between the client and the server is 
secured (aka encrypted). Use SSL/TLS.

> // The password is encrypted, but it does not protect against a MITM attack
> connection.bind( "ou=example, dc=com", "{crypt}wSiewPyxdEC2c" );

What's the point of sending the hash value of your password to a remote 
server, which is likely to store it hashed anyway ? ( and yes, none of 
the two piece of code protect you against a MITM attack. Use a secured 

At this point, I think you totally misunderstood what are the key 
principles of password usage. Let me give you some elements:

* a password's hash is a one-way function that takes a password as an 
input and generate a hash out of it. There is no way you can recover the 
password out of this hash, the only thing you could do is to get some 
collision (ie find some passwords that produces the same hash value). 
The hash function is critical here: it should generate pretty random 
hashes, regardless of the password complexity,  and it should not be too 
fast to slow down a rainbow attack or a brute force attack.

* you should *NEVER* *EVER* store a clear text password *IN A SERVER*. 
*NEVER*. Always store a hash value.

* Use salted versions of algorithm that propose some (SSHA instead of 
SHA, or crypt :

* If your client is going to bind on a remote LDAP server using 
credentials, then *ALWAYS* do so over a secured connection (LDAPS or use 
the startTLS extended operation)

* don't *EVER* code a password as a hard coded string in your code. Make 
it a parameter that is read from a configuration file, or as an user 
input. Of course make sure that your filesystem is secured (aka 
encrypted) when you store passwords in files...

That being said, the reason it does not work with LDAP when you use 
"{crypt}wSiewPyxdEC2c" as a password is that the server will recognize 
the {crypt} at the very beginning of a stored password as a marker for 
some hashed password.

Ldap Server storage:

[on server] <Dumy, userPassword: "{crypt}wSiewPyxdEC2c"> -> means the 
password (say, "MySecret") has been hashed to "wSiewPyxdEC2c" using the 
'crypt' algorithm, which is concatenated to the hash value, for later 
use when the client tries to bind.

Client binding :

[client] Bind( Dummy, "MySecret" ) -> [Server] -> "Ok, I received a Bind 
request for user Dummy, let's fetch his/her password" -> 
{crypt}wSiewPyxdEC2c -> "Ok, this starts with "{crypt}", I must hash the 
received password -> crypt( "MySecret") -> "wSiewPyxdEC2c" -> "Ok, now 
compare the computed hash password of "MySecret" with the stored value : 
compare( "wSiewPyxdEC2c", "{crypt}wSiewPyxdEC2c" ) -> "Ok, let's remove 
'{crypt}' from the stored password" -> hashes are equal, this is the 
correct password, let's allow the user !

Hope it clarifies things...

View raw message