Hallvard B Furuseth wrote:
Thierry Moreau writes:
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.
I like looking at the essence before delving into the details.
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).
Oh yes, in a different context I was exposed to the exact same security
issue. The storage of hash(user, realm, password) is thus even less
secure than hash(password) when the password is received in plain text
form within an encrypted TLS connection, and even dangerous because it
gives a false sense of security.
OpenLDAP uses Cyrus SASL, and whether that supports storing such hashes
instead of plaintext passwords I don't know.
From OpenLDAP guide,
http://www.openldap.org/doc/admin23/sasl.html#DIGEST-MD5
I think the implementation uses plaintext passwords.
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.
That would be something like identity-based public key crypto schemes,
in which, as I understand them, the public key has an embedded encoding
of the user ID. Like other PK schemes, it requires secure storage of
private keys on the client/end-user side. We can't dismiss the "power of
the installed base".
Regards,
--
- Thierry Moreau
CONNOTECH Experts-conseils inc.
9130 Place de Montgolfier
Montreal, Qc
Canada H2M 2A1
Tel.: (514)385-5691
Fax: (514)385-5900
web site: http://www.connotech.com
e-mail: [EMAIL PROTECTED]
---
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.
