On 2003.11.04, russm <[EMAIL PROTECTED]> wrote: > > The ability to have the plaintext passwords stored in some "more > secure" repository on the server side is covered in Digest by the the > ability of the HTTP server to retrieve H(A1) from some other source > (RFC2069, sec. 2.2).
Right. One problem though is that Digest auth. requires the server to store the nonce values on the server for as long as they're valid. If you use one-time nonce's, you have to remember all the nonce's you've issued until they either (a) expire or (b) you've seen them come back in a digest-response. This isn't a hard problem to solve, of course. There's plenty of ways to store server-side data ... ;-) > The Basic/SSL -> "strong authentication token" mechanism you describe > is open to both replay and MITM attacks. To avoid replay you would need > to timeout and renegotiate the tokens (which is provided with Digest's > nonce management). To avoid MITM the token would also need to be > somehow tied to the request URI and body (impossible with cookies, > provided in Digest auth). True. However, folks like Amazon seem to be willing to accept replay and MITM attacks -- they auth. over SSL, then set auth. cookies and downgrade to regular HTTP after authentication. Granted, it's not strong authentication, but if e-commerce at Amazon.com doesn't require it ... what really does? Sometimes, the best solution to a technological problem can be a non-technological one. I wonder what Amazon's fraud policy looks like, and what exposure to risk they're limited to ... > Cryptographically, the correct solution is SSL/TLS. However, in > practice we're not going to be running every single authenticated > connection over SSL any time soon. Right. While ideal, this method is quite costly with the added processing power required, as you point out. > As far as I can tell Digest is a step in the right direction, has > already been specified, and securely* solves the problem it claims to > solve (unencrypted passwords on the wire), which in my opinion puts it > ahead of any ad-hoc homegrown solution to the same problem. [...] > * I haven't seen any reports of weaknesses in Digest's design, and I'm > keen to be informed if I'm wrong on this. What browsers implement Digest auth? Can you use Digest auth without having to pop up a window on the client browser? Silly requirements, but they seem to drive people's decisions on how to implement authentication, strangely enough. -- Dossy -- Dossy Shiobara mail: [EMAIL PROTECTED] Panoptic Computer Network web: http://www.panoptic.com/ "He realized the fastest way to change is to laugh at your own folly -- then you can let go and quickly move on." (p. 70) -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]> with the body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of your email blank.
