[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: comments to draft-ietf-ldapbis-authmeth-04.txt

Hallvard B Furuseth wrote:

I'm still wondering about SASL/DIGEST-MD5...

In an old private mail to Roger Harrison, I wrote:


[Under Security Considerations in Authmeth,]

Please mention (...) which mechanisms that are standardized by the
LDAP standard do/do not disclose the user's password to the server?



Another thing which would be interesting to list is which methods
need/don't need the server to know the user's plaintext password.
(I say 'know' instead of 'store' because it could still store the
password encrypted, but in a way which it knows how to decrypt.)

The best, of course, should be a method which does not require the
server to know the password and does not disclose the password to the
user.  According to rfc2831 SASL/DIGEST-MD5 is such a mechanism, yet
Section 3.9 "Storing passwords" says:

  if this password file is compromised, then an attacker gains
  immediate access to documents on the server using this realm.

I don't see what 'files' means in LDAP context.

password storage.

 Does this mean that
if our system encrypts passwords and throws away the unencrypted ones,

I assumed below that you meant hashing, not encrypting here. Encryption is reversible.

we can't use SASL/DIGEST-MD5 since we must to know the plaintext
passwords and re-encrypt them if the password file is stolen?

You either store hash of username-value, realm-value, and passwd or you store a cleartext password (or encrypted version of it).
If you use different hashing and store only hashes, you can't use DIGEST-MD5.

The phrase

  if this password file is compromised, then an attacker gains
  immediate access to documents on the server using this realm.

means that if you store DIGEST-MD5 hashes and they are stolen, this allows the person who stole them to access your LDAP server. However, imagine that you've stored a hash username:realm1:password on a compromised server A.
If another LDAP server B has an account for the same user "username" with the same password "password", but different realm, the hash from the compromised server is not good on the LDAP server B.

If not - Section 3.9 says the stored passwords will be a hash of
username-value, realm-value, and passwd, and that the realm should
include the name of the host doing the authentication. Will
'ldap.uio.no' do for host here, where that will be the DNS name of
_several_ hosts?


It will, but you risk that a compromise of a server from the list will mean compromise on all of them (assuming they share users).

Have I answered your questions?



Alexey