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!!!
Alberto Moreno portsbsd@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
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
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)
http://tools.ltb-project.org/repositories/entry/ltb/self-service-password/tr...
(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
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 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 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
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).
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
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
On Wed, Sep 30, 2009 at 3:51 AM, Jonathan Clarke jonathan@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:
- 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!!!
openldap-technical@openldap.org
-
Adam Tauno Williams -
Alberto Moreno -
Dieter Kluenter -
Howard Chu -
Jonathan Clarke -
Zdenek Styblik