[Zope] Security glitch on user-editing form

[Phillip J. Eby]

At 03:59 PM 5/11/99 -0400, Rob Page wrote:
>
>As an example of our Open Source business model a current customer is
>rather interested in LDAP and has asked us to develop some Zope
>integration for it.  LDAP stores the _hash_ of users' passwords (e.g.,
>crypt, MD5, SHA).  Our LDAP effort will be very sensitive to this
>approach.
>
>What are people's thoughts on storing password hashes instead of the
>plaintext password?  Of course, it would become impossible to offer the
>"You Forgot Your Password For the Fifteenth Time" email messages...

Actually, it's not impossible, so long as you change their password,
generate a new one, and send it in the message...  :)

Seriously, storing hashes is much more secure than plaintext, IMHO.  If you
have a hash, all you get is the ability to test for possible passwords much
faster.  Granted, this does nothing about the transmission of the plaintext
password to Zope in the first place...

Where LDAP is concerned, I suggest a multi-leveled approach.  First,
encrypt the password stored on the LDAP server.  Second, grant absolutely
no-one the rights to *read* the password value, and only grant *compare*
rights to the application server's login, perhaps restricting the IP/domain
as well.  Rather than using the LDAP bind operation to check the password,
bind as an application server login and keep the connection open.  Use the
compare operation on the encrypted password attribute, so that you are not
retransmitting the user's password in the clear.  Now a hacker has to do a
fair amount just to get to the point where they can start even *guessing*
passwords...  and they still have to try one password at a time against a
single user, unless they can break into the LDAP server's underlying DB.