You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@directory.apache.org by "M. P." <ki...@hotmail.fr> on 2015/12/08 12:09:09 UTC
[ApacheDS] Bind with hashed password
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.
We can bind to this apacheDS server providing plain passwords and also
providing full userPassword fields when password are encrypted in the
directory. I mean providing {enc_mecanism}hashed_password as a password.
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 ?
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)
Thanks for your explanations.
--
------------
M. P.
Re: [ApacheDS] Bind with hashed password
Posted by Emmanuel Lécharny <el...@gmail.com>.
Le 09/12/15 11:32, M. P. a écrit :
> Le 2015-12-08 16:22, Emmanuel Lécharny a écrit :
>>
>>> 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.
>> That's a possibility. Have they added an interceptor, or a specific
>> authenticator ? Adding an authenticator that accepts such broken
>> passwords is a solution that would work.
>
> I don't know. The team currently working on these apps don't know too.
> The guys that worked on that are not there any more. I have to check
> that later.
Check for any classes implementing the Authenticator interface. Here are
the existing ones (in 2.0.0) :
Authenticator
AbstractAuthenticator
AnonymousAuthenticator
DelegatingAuthenticator
DummyAuthenticator
SimpleAuthenticator
StrongAuthenticator
If there is some other, then that means they have added a specific
authenticator.
Same for Interceptors.
Re: [ApacheDS] Bind with hashed password
Posted by "M. P." <ki...@hotmail.fr>.
Le 2015-12-08 16:22, Emmanuel Lécharny a écrit :
> Le 08/12/15 15:48, M. P. a écrit :
>>
>>>
>>> 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 ...
>
> My personal bet : it was a bug in 1.5.7
>
>
>> 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.
> That's a possibility. Have they added an interceptor, or a specific
> authenticator ? Adding an authenticator that accepts such broken
> passwords is a solution that would work.
I don't know. The team currently working on these apps don't know too.
The guys that worked on that are not there any more. I have to check
that later.
--
------------
M. P.
Re: [ApacheDS] Bind with hashed password
Posted by Emmanuel Lécharny <el...@gmail.com>.
Le 08/12/15 15:48, M. P. a écrit :
>
>>
>> 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 ...
My personal bet : it was a bug in 1.5.7
> 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.
That's a possibility. Have they added an interceptor, or a specific
authenticator ? Adding an authenticator that accepts such broken
passwords is a solution that would work.
Re: [ApacheDS] Bind with hashed password
Posted by "M. P." <ki...@hotmail.fr>.
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.
Re: [ApacheDS] Bind with hashed password
Posted by Emmanuel Lécharny <el...@gmail.com>.
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...