directory-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "M. P." <>
Subject Re: [ApacheDS] Bind with hashed password
Date Tue, 08 Dec 2015 14:48:42 GMT
Le 2015-12-08 14:48, Emmanuel Lécharny a écrit :
> Le 08/12/15 12:09, M. P. a écrit :
>> Hi all,
>> I'm working for a new company for some months now and I have as a
>> project to renew our directory server. The company uses ApacheDS 1.5.7
>> and I have a question about it's behaviour.
> Pretty old. Switch to the latest version as fast as possible !

I know. It is a reason for the renew.
>> We can bind to this apacheDS server providing plain passwords and also
>> providing full userPassword fields when password are encrypted in the
>> directory.
> Password are *not* encrypted : they are hashed. This is really a
> different thing.

Right! That was already told me some times ;) When I wrote it was the 
first word that came to my mind (english is not my native language) and 
I have not corrected before sending.
>> I mean providing {enc_mecanism}hashed_password as a password.
> Doh... You mean you actually *can* bind using something like
> {SHA}kfghgkFgvkjh as a credential?

As a password, yes. You're shocked ? Me too !!!
>> This behaviour is very strange for me and in my point of view is a big
>> security issue. What I want to know is how is it possible that you can
>> bind providing hashed password ?
> No, why would you be able to do that ? That would be almost equivalent
> than storing the password in clear text in the server !

I do not want to do that. It is working like that currently. And that is 
what I want to change. And you're right, it is equivalent :/
> OTOH, if ApacheDS 1.5.7 allows such a thing, then it's an obvious bug.
> Now, 1.5.7 is more than 5 years old, so...
>> I ask because some apps here rely on this behaviour/issue and I want
>> to know how I can reproduce it for compatibility reasons ? (that will
>> be discarded later)
> Weird apps that try to bind using a hashed password... This is all but
> safe !

I thought that before but after reflection and debug, the application is 
just sending the credentials to the server. I'm not sure there is any 
api or function that checks password is not hashed before sending them 
to the server.
> Follow me on that :
> - the idea is that the password should *not* be exposed to the world
> - hashing them on the server make them impossible to retreive, if one
> get access to the raw data
> - one condition, of course, is that the original passwords were complex
> enough to not be present in a rainbow dictionary (ie, passwords like
> 'secret', 'system', '007' etc have well known hash, so it's easy to 
> test
> them against the data).
> - when a client connects to a server, it sends its password *in clear 
> text*
> - then the server hashes the received password, and compares it to what
> it has in its database. If it matches, bingo, the client is identified.
> - obviously, as the password is transmitted in clear text, the
> connection *MUST* be safe, thoiugh SSL/TLS
> - Last, not least, you can also use other mechnisms, way safer :
> certificates, for instance, or Kerberos.

I'm aware of that ;)
> Hope you can explain that to your application developpers...

I started to explain them that it should not be done the way it is done 
now. I can provide them a newer version of the directory, more secure, 
but like I said before, they use this behaviour/issue currently and if I 
want to migrate to a newer version, I have to provide them some 
compatibility possibility the time this is fixed in the app.

This is the reason I ask here. Maybe apacheDS was working like this 
before, maybe this is a bug, I don't know what else ...
When searching for an explanation, I saw that there are interceptors in 
apacheDS and as a supposition, maybe playing with them allows apacheDS 
to accept these bindings.

Thanks for the time


M. P.

View raw message