OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   Re: [xml-dev] Re: Cookies at XML Europe 2004 -- Call forParticipation

[ Lists Home | Date Index | Thread Index ]

At 3:32 PM +0000 1/8/04, Alaric B Snell wrote:
>Elliotte Rusty Harold wrote:
>>  At 12:08 PM +0000 1/8/04, Alaric B Snell wrote:
>>
>>>  Yes, Digest auth is pretty good - it'd be great if it was 
>>>implemented widely enough to actually be safely usable, though :-(
>>>
>>  Please elaborate. Is it a browser issue? a server issue? Is it 
>>implemented but just not turned on. Name names. Who deserves praise 
>>and who deserves calumny? Inquiring minds want to know.
>
>Let me see...
>
>http://static.userland.com/userLandDiscussArchive/msg012483.html

That's from 1999. What it says boils down to Netscape 4.x doesn't 
support this. I'd still like to support Netscape 4.x, so that's an 
issue. Still, if anyone has more current information on browser 
support, that would be useful.

>http://www.unixpapa.com/auth/basic.html#sec2.2
>   \-> ('2.2.3. Why Digest Authentication Isn't Used')

This one is a very well-written discussion of how all this works. 
Very useful. Thanks. The key piece of information is this:


      Now versions of it have appeared Internet Explorer 5.0, Mozilla 0.9.7,
      Opera 6. Microsoft's IIS 5.0 server also supports it. Netscape's 
4.0 browers
      do not support it.

      The bad news is, Microsoft implemented it differently than everyone else,
      so IIS only works with IE, and IE only works with IIS. All other 
browsers are
      compatible with Apache, but not IIS. Why are we not surprised?

However, this piece was originally written in 1997 and updated in 
2003 though it's not clear what changed. The browsers mentioined here 
are all a few years old at least. It would be nice to know what the 
current status is. I know people are still using Netscape 4.x and IE 
5. I'd be surprised to see Mozilla 0.97 though. And it's possible the 
bugs in IIS have since been fixed. Does anyone know?

>I came across a page that reminded me of another downside to HTTP 
>auth - there's no way for the server to cancel the session if it 
>believes the session might be compromised (eg, the same user appears 
>to be logging in from two entirely unrelated machines, or trying to 
>brute-force guess something or whatnot) without entirely shutting 
>down the user account,

I'm not sure how this really distinguishes the two options in favor 
of cookies. If implemented, this would help defend against a replay 
attack, but it digest authentication isn't subject to that, unlike 
cookies. If somebody's trying to brute force guess passwords by 
logging in repeatedly, that's pretty much the same issue with either 
cookies or digest authentication. If the same user is logged in from 
two entirely unrelated machines (not impossible of course, but might 
indicate an attack)  using passwords, or in some other way you 
suspect the password has been cracked, then you want to shut off the 
account and reverify via e-mail regardless. I don't see a big 
difference between the two types of authentication here.

>  and browsers don't seem to provide an accessible interface to "log 
>out" by making the browser forget the username/password combo it has 
>stored for the realm there and then at the click of a button.

It is doable, at least in Mozilla, but you're right. It should be easier.

>However, there are still more fundamental issues with authentication 
>mechanisms a little more heavyweight than just a username and 
>password. Eg, there are public key crypto devices such as the Java 
>iButtons that can do a public key signing in a few seconds; this is 
>perfect if you just use that to securely choose a session key while 
>authenticating yourself to the server and can continue to use that 
>session key, but it would be bad to force a two second delay on 
>every HTTP request (especially for image-heavy pages :-)

A lot of pages that use SSL deliberately serve images from a 
different server (or the same server) using plain vanilla http over 
unencrypted TCP for precisely this reason. As long as the images 
themselves aren't secret, there's no need to incur the cost for the 
images.
-- 

   Elliotte Rusty Harold
   elharo@metalab.unc.edu
   Effective XML (Addison-Wesley, 2003)
   http://www.cafeconleche.org/books/effectivexml            
   http://www.amazon.com/exec/obidos/ISBN%3D0321150406/ref%3Dnosim/cafeaulaitA 




 

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS