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