Re: PHP: issues managing the password, what is wrong?

[Zdenek Styblik <stybla@turnovfree.net>]

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@turnovfree.net
jabber: stybla@jabber.turnovfree.net