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 !
>
> 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.
> 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?
>
> 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 !
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 !
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.
Hope you can explain that to your application developpers...
