- From: Jon Hanna <jon@hackcraft.net>
- Date: Tue, 27 Jul 2004 16:14:30 +0100
- To: Matthew Smith <matt@kbc.net.au>
- Cc: WAI Interest Group <w3c-wai-ig@w3.org>
> 1) HTTP Basic Authentication Basic Authentication is even less secure than the better cookie systems. There is no real reason to use it when you can use Digest Authentication instead, however your two issues with Basic also apply to Digest (if less so). > For me, this is the easiest type to use when coding an application - Apache > (the > web server software) looks after everything for me. > > With graphical user agents, the sign-in appears as a pop-up. Does this not > cause a problem with screen readers working with Mozilla/IE/etc. ? It doesn't have to, the browser does have the freedom to prompt in whatever way is appropriate, in theory at least. Also, dialogs aren't quite the same issue as HTML/Javascript pop-ups. > The only other flaw that this has, in my mind, is a security one rather than > one > of accessiblity; as the user agent tends to cache the authentication > information, there is no real way to "log out" without closing the user > agent. Of course that doesn't have to be the case either, it's a design flaw in the current browsers that they don't have a log out command. You can kludge it by having a "logout/log in as different user" link that causes a 401. You can also set the stale flag to false if the timestamp is very old (this doesn't apply to Basic), which will force the user to re-authenticate. [To anyone who isn't familiar with Digest the above statement may seem contradictory. Normally you set the stale flag to mean "the credentials were okay, but the nonce is stale" so the browser won't prompt, it'll just recompute the digest for the fresh nonce with the previous user/pass. Setting the stale flag to false tells the browser it needs to completely redo the authentication procedure). > 2) Cookie Authentication > This would appear quite friendly from a user perspective, but what if the > user > agent does not support cookies? Cookies are friendly? When done well these are generally still less secure than Digest and often they are even less secure than Basic. They also cause serious scaling issues as cookies always do; you shouldn't expect to violate the web architecture and not have to pay for it. They tend to go hand in hand with bad practices such as storing unhashed passwords in the server's database and so on, though there is no reason why this should have to be the case (we all have to build these things when clients insist on them, and some of us try to do our best). Whereas Digest (and Basic) leave it up to the browser to decide how to prompt for the credentials, Cookie based systems rely on the author to build a universally accessible form, so on that basis Digest at least offers better scope for accessibility I suppose. There are also sometimes systems that pass credentials in URIs; Damaging the ability to use the URI itself as part of the UI (if only to users comfortable with doing so), less secure even than cookie or basic systems and with scalability problems as bad, or worse, than the cookie systems. -- Jon Hanna <http://www.hackcraft.net/> …it has been truly said that hackers have even more words for equipment failures than Yiddish has for obnoxious people." - jargon.txt
Received on Tuesday, 27 July 2004 11:17:44 UTC