Thierry Moreau writes: >Hallvard B Furuseth wrote: >>Thierry Moreau writes: >>>I know that some protocol-side (challenge-response type) require >>>in-memory access to plain text passwords, which can not be recovered >>>from hashed or salted hashed representations. >> >> I'm not quite sure what you mean here... To bind with a password, the >> client needs to learn the password. How it stores it, and any key >> management on the client side, is not an LDAP matter. > > I mean a server-side requirement to handle plain text passwords, this > requirement being induced by the design of a challenge-response > protocol, i.e. the SASL DIGEST-MD5 mechanism.
Not quite. The DIGEST-MD5 challenge includes <random1, realm> and the client response includes <random2, user, f(random1, random2, hash(user, realm, password))> Well, it's a bit more complicated, but that's the essence. But the server is only required to store hash(user, realm, password), so it can compute f() and compare. However an attacker who gets access to a user's stored hash can still authenticate as the user. So if the server's password file is compromised, one must choose a new realm and compute new hashes for all the users (which might also mean all users will need new passwords, if they are not stored somewhere). OpenLDAP uses Cyrus SASL, and whether that supports storing such hashes instead of plaintext passwords I don't know. About SASL mechanisms, check out the [EMAIL PROTECTED] archive at <http://www.imc.org/ietf-sasl/mail-archive/>. There has been mention of some new methods to replace DIGEST-MD5, but I haven't checked how they work. I wonder if a SASL mechanism could use public key methods instead of comparing hashes, so a stored password crypt would be the equivalent of the public key and couldn't be used to compute what to send to the server. Would need to bake in extra random numbers as well to avoid replay attacks. -- Regards, Hallvard --- You are currently subscribed to [EMAIL PROTECTED] as: [EMAIL PROTECTED] To unsubscribe send email to [EMAIL PROTECTED] with the word UNSUBSCRIBE as the SUBJECT of the message.
