5:51 p.m.
Hi people, I doing a web interface that will request a username +
password, like squirrelmail i will contact my ldap server, this app
will run on Centos 5.3, php 5.3, this will be where my web pages will
be, the ldap server is running on Gentoo with ldap 2.3.43.
My current problem is with the password, I have found small app that
wants to compare the input of the password vs the ldap password this
will let us identify the user.
Well searching aroun, I found the crypt function but there is a
thing that I don't like it:
"The standard DES-based encryption crypt() returns the salt as the
first two characters of the output. It also only uses the first eight
characters of str , so longer strings that start with the same eight
characters will generate the same result (when the same salt is used)"
How can I deal with this note: 8 characters only?
Some users have more than that, this is my code:
$cryptedpassword='{crypt}74boAULE9gF5.';
if( preg_match( "/{([^}]+)}(.*)/", $cryptedpassword, $cypher ) ) {
$cryptedpassword = $cypher[2];
$_cypher = strtolower($cypher[1]);
} else {
$_cypher = NULL;
}
if( preg_match("/^\\$2+/",$cryptedpassword ) ) {
// make sure that web server supports blowfish crypt
if( ! defined( 'CRYPT_BLOWFISH' ) || CRYPT_BLOWFISH == 0 )
pla_error( _('Your system crypt library does not
support blowfish encryption.') );
list(,$version,$rounds,$salt_hash) =
explode('$',$cryptedpassword);
if( crypt( $plainpassword, '$'. $version . '$' .
$rounds . '$' .$salt_hash ) == $cryptedpassword )
return true;
else
return false;
}
elseif( strstr( $cryptedpassword, '$1$' ) ) {
if( ! defined( 'CRYPT_MD5' ) || CRYPT_MD5 == 0 )
pla_error( _('Your system crypt library does not
support md5crypt encryption.') );
list(,$type,$salt,$hash) = explode('$',$cryptedpassword);
if( crypt( $plainpassword, '$1$' .$salt ) == $cryptedpassword )
return true;
else
return false;
}
elseif (strstr( $cryptedpassword, '_' ) ) {
if ( ! defined( 'CRYPT_EXT_DES' ) || CRYPT_EXT_DES == 0 )
pla_error( _('Your system crypt library does not
support extended DES encryption.') );
echo crypt($plainpassword, $cryptedpassword );
if( crypt($plainpassword, $cryptedpassword ) ==
$cryptedpassword )
return true;
else
return false;
}
else {
if( crypt($plainpassword $cryptedpassword ) == $cryptedpassword)
return true;
else
return false;
}
The issue is the 8 character limitation, even If i have a password
of 10 characters, the function will just take 8, how can I deal with
this issue?
Thanks for your time my firiends!!!
--
LIving the dream...
10:32 p.m.
Alberto Moreno <portsbsd(a)gmail.com> writes:
Hi people, I doing a web interface that will request a username +
password, like squirrelmail i will contact my ldap server, this app
will run on Centos 5.3, php 5.3, this will be where my web pages will
be, the ldap server is running on Gentoo with ldap 2.3.43.
My current problem is with the password, I have found small app that
wants to compare the input of the password vs the ldap password this
will let us identify the user.
This application is broken and raises a security issue. The proper way
is to do a bind with the provided credentials. Furthermore you cannot
do a ldapcompare with hashed passwords.
[...]
-Dieter
--
Dieter Klünter | Systemberatung
http://dkluenter.de
GPG Key ID:8EF7B6C6
53°37'09,95"N
10°08'02,42"E
10:43 p.m.
Hello,
Alberto Moreno wrote:
...
My current problem is with the password, I have found small app that
wants to compare the input of the password vs the ldap password this
will let us identify the user.
As Dieter already said, wrong. Authenticate directly with provided
credentials, or use "proxy" user to search for uid resp. DN, then try to
authenticate against it with provided credentials.
Well searching aroun, I found the crypt function but there is a
thing that I don't like it:
"The standard DES-based encryption crypt() returns the salt as the
first two characters of the output. It also only uses the first eight
characters of str , so longer strings that start with the same eight
characters will generate the same result (when the same salt is used)"
How can I deal with this note: 8 characters only?
I believe this is broken, or obsolete. I'm using Perl port of Unix
crypt() function, and it works just fine for "any" password lengths.
8 characters limitation sounds like - history :)
Zdenek
--
Zdenek Styblik
Net/Linux admin
OS TurnovFree.net
email: stybla(a)turnovfree.net
jabber: stybla(a)jabber.turnovfree.net
2:22 a.m.
On 30/09/2009 07:43, Zdenek Styblik wrote:
Hello,
Alberto Moreno wrote:
...
>
> My current problem is with the password, I have found small app that
> wants to compare the input of the password vs the ldap password this
> will let us identify the user.
>
As Dieter already said, wrong. Authenticate directly with provided
credentials, or use "proxy" user to search for uid resp. DN, then try to
authenticate against it with provided credentials.
Absolutely. You'll find an open source example of this in PHP here
(I'm sure there are many on the web, this one came to hand)
(lines 50 to 92)
> Well searching aroun, I found the crypt function but there is
a
> thing that I don't like it:
>
> "The standard DES-based encryption crypt() returns the salt as the
> first two characters of the output. It also only uses the first eight
> characters of str , so longer strings that start with the same eight
> characters will generate the same result (when the same salt is used)"
>
> How can I deal with this note: 8 characters only?
>
I believe this is broken, or obsolete. I'm using Perl port of Unix
crypt() function, and it works just fine for "any" password lengths.
8 characters limitation sounds like - history :)
Actually crypt() is system-dependant. Different *nixes implement it
differently. Many implementations accept passwords of any length, but
only use the first 8 characters to create the hash. As a result, using
crypt passwords is insecure and un-portable.
So, yes, it sounds like history, but that's crypt for you :)
Regards,
Jonathan
2:54 a.m.
Jonathan Clarke wrote:
On 30/09/2009 07:43, Zdenek Styblik wrote:
...
>
> I believe this is broken, or obsolete. I'm using Perl port of Unix
> crypt() function, and it works just fine for "any" password lengths.
> 8 characters limitation sounds like - history :)
Actually crypt() is system-dependant. Different *nixes implement it
differently. Many implementations accept passwords of any length, but
only use the first 8 characters to create the hash. As a result, using
crypt passwords is insecure and un-portable.
So, yes, it sounds like history, but that's crypt for you :)
Regards,
Jonathan
Errr ... well, it seems so.
I think I've hit the wall with eg. sshd x nss-switch when having
passwords crypted by anything else than crypt();
Also, using SSHA might be a bit of overkill (I'm not defending crypt()! :))
So, what's left? Or more, what's the suggestion - which crypt function
to use? Having passwords in MD5/SHA is just - it doesn't sound too much
secure (neither is crypt()), even if those are portable.
I'd say it depends on the type of leak of credentials - if database is
stolen, or password is sniffed through eg. http [web app] - in the first
case, hashed passwords will buy time; the second - it doesn't matter,
how's the password stored in LDAP - right?
Probably a bit off-topic.
Regards,
Zdenek
--
Zdenek Styblik
Net/Linux admin
OS TurnovFree.net
email: stybla(a)turnovfree.net
jabber: stybla(a)jabber.turnovfree.net
3:14 a.m.
Zdenek Styblik wrote:
Jonathan Clarke wrote:
> On 30/09/2009 07:43, Zdenek Styblik wrote:
> ...
>>
>> I believe this is broken, or obsolete. I'm using Perl port of Unix
>> crypt() function, and it works just fine for "any" password lengths.
>> 8 characters limitation sounds like - history :)
>
> Actually crypt() is system-dependant. Different *nixes implement it
> differently. Many implementations accept passwords of any length, but
> only use the first 8 characters to create the hash. As a result, using
> crypt passwords is insecure and un-portable.
>
> So, yes, it sounds like history, but that's crypt for you :)
>
> Regards,
> Jonathan
Errr ... well, it seems so.
I think I've hit the wall with eg. sshd x nss-switch when having
passwords crypted by anything else than crypt();
nsswitch should not be used to authenticate against LDAP. That's what PAM is
for. Clients should never know (let alone care) how the password is stored
inside the LDAP server.
Also, using SSHA might be a bit of overkill (I'm not defending
crypt()! :))
So, what's left? Or more, what's the suggestion - which crypt function
to use?
SSHA is the default; if you have to ask then you probably shouldn't change it.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
3:32 a.m.
Howard Chu wrote:
Zdenek Styblik wrote:
> Jonathan Clarke wrote:
>> On 30/09/2009 07:43, Zdenek Styblik wrote:
>> ...
>>>
>>> I believe this is broken, or obsolete. I'm using Perl port of Unix
>>> crypt() function, and it works just fine for "any" password
lengths.
>>> 8 characters limitation sounds like - history :)
>>
>> Actually crypt() is system-dependant. Different *nixes implement it
>> differently. Many implementations accept passwords of any length, but
>> only use the first 8 characters to create the hash. As a result, using
>> crypt passwords is insecure and un-portable.
>>
>> So, yes, it sounds like history, but that's crypt for you :)
>>
>> Regards,
>> Jonathan
>
> Errr ... well, it seems so.
> I think I've hit the wall with eg. sshd x nss-switch when having
> passwords crypted by anything else than crypt();
nsswitch should not be used to authenticate against LDAP. That's what
PAM is for. Clients should never know (let alone care) how the password
is stored inside the LDAP server.
I'm not going to flame over PAM, but thanks (and no thanks - no offense).
I have no knowledge of how Padl's nss-switch works, neither I've said
client should know anything about how's password encrypted.
If nss-switch is incapable of handling anything else than crypt because
of bad design (or what), then it's sad.
> Also, using SSHA might be a bit of overkill (I'm not
defending
> crypt()! :))
> So, what's left? Or more, what's the suggestion - which crypt function
> to use?
SSHA is the default; if you have to ask then you probably shouldn't
change it.
I think not using SSHA was recommended somewhere, because it's
heavyweight. It was probably an old book :)
Once again, I'm not *for* any specific crypto function.
Zdenek
--
Zdenek Styblik
Net/Linux admin
OS TurnovFree.net
email: stybla(a)turnovfree.net
jabber: stybla(a)jabber.turnovfree.net
3:44 a.m.
>>>> I believe this is broken, or obsolete. I'm using
Perl port of Unix
>>>> crypt() function, and it works just fine for "any" password
lengths.
>>>> 8 characters limitation sounds like - history :)
>>> Actually crypt() is system-dependant. Different *nixes implement it
>>> differently. Many implementations accept passwords of any length, but
>>> only use the first 8 characters to create the hash. As a result, using
>>> crypt passwords is insecure and un-portable.
>>> So, yes, it sounds like history, but that's crypt for you :)
>> Errr ... well, it seems so.
>> I think I've hit the wall with eg. sshd x nss-switch when having
>> passwords crypted by anything else than crypt();
> nsswitch should not be used to authenticate against LDAP. That's what
> PAM is for. Clients should never know (let alone care) how the password
> is stored inside the LDAP server.
I'm not going to flame over PAM, but thanks (and no thanks - no offense).
There is no flame here - just a technical fact. PAM is for
authentication, NSS is for identity. There is nothing wrong at that
level - your application is broken [as was mentioned in a previous
message].
I have no knowledge of how Padl's nss-switch works, neither
I've said
client should know anything about how's password encrypted.
If nss-switch is incapable of handling anything else than crypt because
of bad design (or what), then it's sad.
NSS doesn't handle passwords AT ALL. It turns "user number 101" into
"fred" and vice versa (UIDs/GIDs being like SIDs/RIDs in Windows - they
usually are turned into a name [login]).
>> Also, using SSHA might be a bit of overkill (I'm not
defending
>> crypt()! :))
>> So, what's left? Or more, what's the suggestion - which crypt function
>> to use?
> SSHA is the default; if you have to ask then you probably shouldn't
> change it.
I think not using SSHA was recommended somewhere, because it's
heavyweight. It was probably an old book :)
Once again, I'm not *for* any specific crypto function.
But you are using crypto methods in your application, which is broken
behavior. Use TLS to encrypt authentication with the DSA and let the
DSA check the password using an ldap compare operation. Communication
is secure and the DSA never reveals the password (encrypted or
otherwise).
2:24 p.m.
Adam Tauno Williams wrote:
>>>>> I believe this is broken, or obsolete. I'm
using Perl port of Unix
>>>>> crypt() function, and it works just fine for "any" password
lengths.
>>>>> 8 characters limitation sounds like - history :)
>>>> Actually crypt() is system-dependant. Different *nixes implement it
>>>> differently. Many implementations accept passwords of any length, but
>>>> only use the first 8 characters to create the hash. As a result, using
>>>> crypt passwords is insecure and un-portable.
>>>> So, yes, it sounds like history, but that's crypt for you :)
>>> Errr ... well, it seems so.
>>> I think I've hit the wall with eg. sshd x nss-switch when having
>>> passwords crypted by anything else than crypt();
>> nsswitch should not be used to authenticate against LDAP. That's what
>> PAM is for. Clients should never know (let alone care) how the password
>> is stored inside the LDAP server.
> I'm not going to flame over PAM, but thanks (and no thanks - no offense).
There is no flame here - just a technical fact. PAM is for
authentication, NSS is for identity. There is nothing wrong at that
You haven't seen my application, so please, be slower on your judgments.
If nss_ldap is broken, then it is. It is not mine application, I haven't
written it and so on. I've acknowledged this [broken] state, I'm fully
aware of it, yet there is "nothing" I can do about it now.
level - your application is broken [as was mentioned in a previous
message].
It sounds to me like you've merged couple conversations together.
> I have no knowledge of how Padl's nss-switch works, neither I've said
> client should know anything about how's password encrypted.
> If nss-switch is incapable of handling anything else than crypt because
> of bad design (or what), then it's sad.
NSS doesn't handle passwords AT ALL. It turns "user number 101" into
"fred" and vice versa (UIDs/GIDs being like SIDs/RIDs in Windows - they
usually are turned into a name [login]).
As I've said, I have no idea how Padl's application work. I think I was
clear about this. I'd expect it to beat out info out of LDAP - actually
more than just UID/GID as /etc/nsswitch.conf provides more - and pass it
via system functions (or whatever) to other applications. So, I'd expect
it to look into LDAP, search for attribute 'userPassword' and return
this attribute in the format as it is described in manual page of
crypt(), or do it "correct" way.
Again, I don't know how is it hooked up [and never cared before].
>>> Also, using SSHA might be a bit of overkill (I'm not
defending
>>> crypt()! :))
>>> So, what's left? Or more, what's the suggestion - which crypt
function
>>> to use?
>> SSHA is the default; if you have to ask then you probably shouldn't
>> change it.
> I think not using SSHA was recommended somewhere, because it's
> heavyweight. It was probably an old book :)
> Once again, I'm not *for* any specific crypto function.
But you are using crypto methods in your application, which is broken
behavior. Use TLS to encrypt authentication with the DSA and let the
DSA check the password using an ldap compare operation. Communication
is secure and the DSA never reveals the password (encrypted or
otherwise).
Yes. Or is there some other way how to change attribute 'userPassword',
because I haven't figured out that yet. So yes, my web app *is*
operating with crypto functions (Unix crypt and SSHA are supported right
now, SSHA is in use) and it seems to be just fine to generate hash and
update it via LDAP [modify] query.
Speaking of authentication part, I did it up to specifics discussed here
[1]. I doubt those are 'broken'. And I've never said it should be
implemented otherwise.
I just don't know where you got these assumptions :\
It might sound like I'm offended [or trying to offend], but I'm alright.
Yet I feel sorry for your [imho wrong] assumptions, or prejudices (?),
about implementations I've done.
Zdenek
[1] http://www.openldap.org/lists/openldap-technical/200906/msg00306.html
--
Zdenek Styblik
Net/Linux admin
OS TurnovFree.net
email: stybla(a)turnovfree.net
jabber: stybla(a)jabber.turnovfree.net
3:51 a.m.
On 30/09/2009 11:54, Zdenek Styblik wrote:
I'd say it depends on the type of leak of credentials - if
database is
stolen, or password is sniffed through eg. http [web app] - in the first
case, hashed passwords will buy time; the second - it doesn't matter,
how's the password stored in LDAP - right?
Several different cases here:
1) Database is stolen: the stronger the hash algorithm, the more time
you buy.
2) Password is sniffed in plain text: hash-independant, since the
attacker already has clear text password
3) Brute force attack by attempting to bind to LDAP server: if the hash
only takes 8 characters into account, that makes brute-forcing a lot
easier - limited number of possibilities. Other than that, hashes should
be equivalent in this case, aside from server load.
Of course, there are other considerations, such as password policy
locks, password complexity and of course users with post-it notes.
Back to the original topic though: the way a password is stored is
really only the LDAP server's business. As Howard said, OpenLDAP uses
SSHA by default - unless you notice some performance hit from that,
there's no reason to change it.
Jonathan
10:02 a.m.
On Wed, Sep 30, 2009 at 3:51 AM, Jonathan Clarke
<jonathan(a)phillipoux.net> wrote:
On 30/09/2009 11:54, Zdenek Styblik wrote:
>
> I'd say it depends on the type of leak of credentials - if database is
> stolen, or password is sniffed through eg. http [web app] - in the first
> case, hashed passwords will buy time; the second - it doesn't matter,
> how's the password stored in LDAP - right?
Several different cases here:
1) Database is stolen: the stronger the hash algorithm, the more time you
buy.
2) Password is sniffed in plain text: hash-independant, since the attacker
already has clear text password
3) Brute force attack by attempting to bind to LDAP server: if the hash only
takes 8 characters into account, that makes brute-forcing a lot easier -
limited number of possibilities. Other than that, hashes should be
equivalent in this case, aside from server load.
Of course, there are other considerations, such as password policy locks,
password complexity and of course users with post-it notes.
Back to the original topic though: the way a password is stored is really
only the LDAP server's business. As Howard said, OpenLDAP uses SSHA by
default - unless you notice some performance hit from that, there's no
reason to change it.
Jonathan
Guys I appreciated this help. Clarke I had found what I was locking
in the link u give me, it is clear and already
customize for me.
I have learn to much with this post, I had been searching around
without any luck, but now is more clear to me.
Thanks again for your help and acknolegde to all of u!!!
--
LIving the dream...
4931
days inactive
4931
days old
openldap-technical@openldap.org
10 comments
6 participants
participants (6)
-
Adam Tauno Williams -
Alberto Moreno -
Dieter Kluenter -
Howard Chu -
Jonathan Clarke -
Zdenek Styblik