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.

Reply via email to