|
> Roger Harrison wrote:
>
> Section 6.2 - I guess this is the best we can do, but returning > confidentialityRequired is a bit like closing the barn gate after the > horses have already left. I.e., the user's password has already gone > over the wire in the clear. I don't know if this is the appropriate > place to make policy recommendations, but it might make sense to > recommend that if the correct password was given, it be > flagged/expired/invalidated and the user forced to set a new password > upon authenticating successfully with proper protections in place. (I > suppose it is inappropriate for this doc, since the LDAP password policy > mechanism is still a work in progress?) This seems like a reasonable concern. I'm wondering if a little more detail in this security consideration might be warranted. Suggested wording:
The server returns a resultCode of confidentialityRequired for the operation (i.e. name/password Bind with password value, SASL Bind transmitting a password value in the clear, add or modify including a userPassword value, etc.), even if the password value is correct. Server implementations may also want to provide policy mechanisms to invalidate or otherwise protect accounts in situations where a server detects that a correct password for an account has been transmitted in the clear.
Comments?
> -- > -- Howard Chu > Chief Architect, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc > OpenLDAP Core Team http://www.openldap.org/project/ Roger Harrison
Novell, Inc.
|