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
>>> 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).
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
> 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
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.