directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Norval Hope" <nrh...@gmail.com>
Subject Re: support for {SHA} admin password in server.xml
Date Mon, 08 Jan 2007 01:04:01 GMT
> The current behavior is that if a user password is stored one way
> encrypted in the partition, and a client uses the clear text value
> during a bind request, he is authenticated (if the hash value of the
> clear text password corresponds to the stored value for the user). This
> is independent from enabling/using LDAPS.
>
> Providing the hashed value of the userpassword attribute instead of the
> original value will be rejected by ApacheDS. This is intended. If
> someone was able to catch this value (from an LDIF export for instance),
> s/he must still provide the password itself in order to get authenticated.
>
>  From the client point of view, both is described with samples here:
> http://cwiki.apache.org/DIRxSRVx10/authentication-options.html#Authenticationoptions-Passwordsstoredonewayencrypted
>
> I hope this helps,
>     Greetings, Stefan
>
>
Thanks, that clears things up for me...and congrats on the wiki
documentation you pointed me at, it is most impressive!

My only remaining concern is that the clear text admin password is
stored in server.xml (which motivated my change), in case this file is
compromised somehow (i.e. installed with wrong permissions etc) in
which case the admin password becomes known regardless of whether the
version stored in the partition itself is one-way hashed.

So my understanding is that (even with my change to support one-way
hash in server.xml) users must choose between exactly one of these
options:
    a) use one-way hashes for passwords persistently stored in AD partitions  OR
    b) use one-way hash for admin password stored in server.xml

It seems a shame that a user can't have both a) and b) at the same
time. I currently have to choose b) because of my company's installer
standards but I can see that not having a) raises an even more serious
security hardness problem.

Mime
View raw message