Ok, I'm likely mistaken on this. I'm checking on the source. However I agree that you wouldn't want Digest Auth over SSL anyway.<br><br>
<div><span class="gmail_quote">On 2/16/06, <b class="gmail_sendername">Andrew Milton</b> <<a href="mailto:akm@theinternet.com.au">akm@theinternet.com.au</a>> wrote:</span>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">+-------[ michael nt milne ]----------------------<br>| No, I read that for digest authentication to work the authentication data can't
<br>| be encrypted. Therefore it seems perfect for implementing more security on<br>| non-SSL sites or sites that don't need SSL but need more security on logon.<br><br>This is baloney. The underlying transport has nothing to do with the incoming data.
<br><br>In Digest Auth the browser 'hashes' the username and password the user enters and simply<br>sends the hash. The webserver does the same and compares the hash to the<br>hash sent by the browser. If they match then you're allowed in.
<br><br>In Basic Auth the username and password are sent base64 encoded.<br><br>Perhaps you were confused about the password being stored encrypted ON THE WEB<br>SERVER. The client and the server both need to agree on what they're hashing
<br>in order to get a common hash. This doesn't mean you can't store the digest<br>hash instead of the normal password hash when creating/changing passwords.<br><br>In any case Digest Auth doesn't gain you anything if you're already on an SSL
<br>connection. It's there to prevent the password from being sent in the clear.<br><br>--<br>Andrew Milton<br><a href="mailto:akm@theinternet.com.au">akm@theinternet.com.au</a><br></blockquote></div><br><br clear="all"><br>
-- <br>Michael