W3C home > Mailing lists > Public > w3c-wai-ig@w3.org > July to September 2004

Re: Accessibility of Pages Requiring Sign-In

From: Jon Hanna <jon@hackcraft.net>
Date: Tue, 27 Jul 2004 16:14:30 +0100
Message-ID: <1090941270.41067156558aa@82.195.128.192>
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

This archive was generated by hypermail 2.3.1 : Wednesday, 5 February 2014 23:39:44 UTC