[whatwg] HTLM5 - Addressing the Password Craze?
davebacher at hotmail.com
Thu Sep 7 17:38:36 PDT 2006
Why not just issue a TLS 1 certificate?
Internet Explorer 2 and later support it. Netscape Navigator 2 and
later support it. All versions of Opera support it. All versions of
FireFox support it. All versions of Safari support it. In fact, the
vast majority of libraries and user agents that support TLS or even SSL
websites also support TLS 1 client certificates.
When you issue the certificate, most browsers offer a convenient way to
send it to the client. It is installed into the local certificate
store, or potentially a hardware device such as a smart card. Later,
the user authenticates to the user agent, and then is given the option
of providing the certificate to a site that asks for it. You can either
issue a certificate specifically for your site, or you can have them go
get a (freely available, in at least some cases) client certificate from
a vendor like VeriSign. These are typically called "e-mail signing
certificates" or "digital ID's" by the companies that sell them.
There are a couple big benefits here. First, you are using an existing
user agent feature, that every user agent is likely to support. So you
just have to talk the user through installing the certificate into IE.
Secondly, web server side, it is a radio button in IIS 4 or later (not
sure about earlier versions), or a single line in Apache to enable the
Thirdly, if the ID becomes compromised, you can issue a revoke request,
and issue a new ID. This means the certificate that you issued before
immediately becomes invalid, and so if the user loses the certificate or
has it stollen, it takes no effort.
Fourthly, if the computer has a smart card reader (about USD $20) and a
smart card, the certificate can be installed onto the smart card. If
this is done, then the user must provide a valid PIN in conjunction with
the physical card in order to send data using the identities installed
onto the card. This adds a physical layer of security that is not
possible with a name/password system.
And the worse problem than the number of systems using user id/password
on a form to authenticate (and not at least using digest) is that many
of these don't use TLS, and so the password is sent plain text or plain
text equivalent across the network. Additionally, many of these systems
send the username and password pair by e-mail, which means not only is
the user name and password sent across the internet, but also that it is
stored in one or more well known locations on the user's computer for at
least some period of time. Since most operating systems don't provide
any mechanism to lock down a directory so that only one module or
application can access it, and since the most protection most user
agents offer to e-mail files is the non-protection of a randomly
generated file name, this is actually the worst part of the security risk.
Failing TLS, most servers (including IIS and Apache) and user agents
support Kerberos, NTLM and a host of other options, and there are
several publicly available specifications for what is called "Federated
Identity." The problem with all of these is that various parties have
interests in pushing their own view of how a federated identity should
work, usually to further their own goals.
Also, keep in mind that a federated identity system also poses privacy
risks for the user. When the user connects to your site, you must
contact the federation and ask if they are who they say that they are.
This means the federation knows both who you are, and what site you are
trying to access. This is why they aren't popular.
TLS doesn't have that problem, because you retrieve a certificate
revocation list versus asking if a specific certificate is valid. All
that verisign (as an example) knows is that a TLS website asked for a
revocation list, they don't ever know what user it was who was trying to
access the site.
The issue with a federated log on is you must log on and log off from
the federation site. Sites have to check with that site to see if your
token is valid or not, so any token based authentication inherently
compromises your privacy (at least potentially).
Anders Rundgren wrote:
> Dear all,
> As you probably have noticed, practically every site offers a login.for their
> members, customers, citizens etc. etc.
> There are two problems here.
> 1. User-id/password management has become a real nuisance. Once this was
> an issue for computer professionals only, now it affects everyone from children
> to grandma.
> 2. There are other and better authentication methods available that become hard
> to migrate to without making life hard for end-users by asking them to use another
> login method. The site has no way of detecting the user's options.
> It appears, that it may be possible to add some kind of negotiation/option
> elements at the HTML level, that if supported by the underlying system could
> offer a standardized and potentially more powerful version of the password
> caches or external login form "hijacker software" that we currently use.
> Tentative functionality for the AHE (Authentication Helper Extension):
> - Find out if the AHE is installed/available
> - If the AHE is available, find out if the site in question is in the list
> - If in the list, put out a dialog box giving the user an option to login, decline
> or manually enter login information.
> - If the site so requests, the user's authentication options (in case form based
> authentication was used) can be transferred during login, giving the site an
> option to ask/require the user to upgrade their authentication. This could
> involve anything from digest-authentication to certificates. The latter
> current lacks a decent provision method but there is some work
> going on in this area as well. MS CardSpaces is also an option.
> - The authentication stuff would be possible to store in an USB token or
> even better in a mobile phone. This is of course outside of HTML5
> but will be natural to support within 3-5 years from now.
> - The scheme would (if properly implemented) be able to thwart phishing
> since a user-id/password (or other auth solution) could be tied to a
> SSL root + host name (or even better host domain).
> In essence the desired result is a portable (mobile) multi-site authentication
> support mechanism that should not only make the web easier, but also
> long-term considerably more secure.
> Other Options?
> The other option is addressing this problem at the transport level but I think
> form-based authentication is a better entrance point since it is already in place.
> There is no problem [at all] of having a mechanism [in the proposed scheme]
> that switches from form-based authentication to transport-level authentication
> like using TLS-client-certificates, while the opposite is impossible.
> Anders Rundgren
More information about the whatwg