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...
http://directory.apache.org/api/five-minutes-tutorial.html
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
connection).
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 : https://en.wikipedia.org/wiki/Crypt_(C))
* 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...
