Andrew Findlay wrote: > On Wed, Mar 13, 2013 at 11:39:28PM +0100, Michael Ströder wrote: > >> http://www.ietf.org/internet-drafts/draft-stroeder-hashed-userpassword-values-01.txt > > In section 3 Implementation Issues, the 4th paragraph talks > about checking the syntax of the storage scheme. This > certainly has to be done, but I am a bit worried by the last > sentence: > > Any value which do not adhere to this syntax MAY be treated as > clear-text password by the DSA when processing a LDAP simple > bind request or LDAP compare request. > > This is probably what most servers actually do, but it does > mean that any unrecognised schemes or badly-formatted values > effectively become clear-text passwords. Not a good failure > mode...
I know that this sounds kinda problematic but what is the actual risk? The risk depends on how predictable the incorrect value is. It would be good to know how the various server implementors handle this. Also see this in the context with the paragraph following the above citation: Servers MAY provide local configuration items to limit the set of hash schemes to be processed and for completely disabling use of clear-text passwords in attribute 'userPassword'. The "MAY provide" here sounds too weak from a security perspective but using SHOULD would be too strong. Maybe it could be replaced by a lower-cased "should consider to provide". > This is another case where the use of standard-setting words > like MAY and SHOULD sits uneasily with the informational > status of the document. Agreed. > From a security perspective I would > prefer something like this: > > Any value which does not have correct syntax SHOULD be > treated as a value that can never match any password > asserted by a user. The condition "does not have correct syntax" cannot be resolved because the syntax definition starts with: userpasswordvalue = cleartext-password / ( prefix hashed-password ) > On the other hand, as a description of current practice it may > be better to say: > > The treatment of values with incorrect syntax is > defined by the server implementation. Administrators > should be aware that servers may treat such values as > clear-text passwords, thus removing the benefit of > hashing entirely. Values using storage schemes not > known to the server may have the same effect. That's better. But I'm not sure whether administrator is a usual term in this type of documents. Ciao, Michael.
smime.p7s
Description: S/MIME Cryptographic Signature
