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

Re: authmeth: passwords in the clear



At 10:44 AM 3/9/2004, Hallvard B Furuseth wrote:
>Kurt D. Zeilenga writes:
>>At 08:53 AM 2/28/2004, Hallvard B Furuseth wrote:
>>>authmeth-10 says:
>>>
>>>> 11. General Requirements for Password-based Authentication
>>>> (...)
>>>>   To mitigate the security risks associated with the use of passwords, 
>>>>   a server implementation MUST implement a configuration that at the 
>>>>   time of authentication or password modification, requires: 
>> (...)
>>>
>>>This should only apply to cleartext passwords, not e.g. modifications of
>>>attributes that contain encrypted passwords.
>> 
>> I concur that this particular section should be limited to
>> cleartext passwords used in authentication.  
>
>I didn't say that (that it should only be about authentication).  I
>agree that a "MUST" is too strong for other operations than
>authentication.  However, it really is the same issue - protecting
>passwords - for other operations.  I suggest a paragraph at the end of
>this section that it is RECOMMENDED that the configuration in question
>treats other operations that contain cleartext passwords, such as
>passwords modifications, the same way.
>Or if not:
>
>> I think other "uses" of cleartext passwords (such as modification)
>> should be address in documents detail specific mechanisms (e.g.,
>> LDAP Password Modify Operation) and/or password schema.
>
>Then most password-related operations and password attributes will end
>up with different ways to treat passwords vs. protection mechanisms, and
>the server may have to implement them all. Whatever we do, I'd prefer a
>single section in [Authmeth] or [Protocol] which suggests how to deal
>with passwords in non-bind operations.  Then the Password Modify
>Operation, the userPassword definition and so on could refer to that if
>they wish.

Well, we might be able to include a security consideration in
[AuthMeth] (or [Protocol]) which not only covers use of clear
text passwords in Bind operations, but use of clear text passwords
in other operations (add, compare, modify, search), but this can
be difficult to accomplish.

My current thinking is that this should be worded more as a security
consideration that specific implementation requirements.

>> (And,
>> aside from some very general guidance, issues associated with
>> gateways, caching proxies, chaining servers, and/or replicas
>> should be addressed in documents discussing such these things.)
>
>Yes.  Maybe such general guidance should be included in the section
>about passwords in non-bind LDAP operations.