+-------[ michael nt milne ]----------------------
| No, I read that for digest authentication to work the authentication data
| be encrypted. Therefore it seems perfect for implementing more security on
| non-SSL sites or sites that don't need SSL but need more security on logon.
This is baloney. The underlying transport has nothing to do with the incoming
In Digest Auth the browser 'hashes' the username and password the user enters
sends the hash. The webserver does the same and compares the hash to the
hash sent by the browser. If they match then you're allowed in.
In Basic Auth the username and password are sent base64 encoded.
Perhaps you were confused about the password being stored encrypted ON THE WEB
SERVER. The client and the server both need to agree on what they're hashing
in order to get a common hash. This doesn't mean you can't store the digest
hash instead of the normal password hash when creating/changing passwords.
In any case Digest Auth doesn't gain you anything if you're already on an SSL
connection. It's there to prevent the password from being sent in the clear.
Zope maillist - Zope@zope.org
** No cross posts or HTML encoding! **
(Related lists -