[whatwg] HTLM5 - Addressing the Password Craze?

[George Staikos]

I would like to add a few more points here.

1) The hardware is very cumbersome.  It's not pervasive, it requires carrying 
cards and tokens, and limits mobility.
2) Certificates are more easily stolen than passwords unless the certificates 
have passwords on them.  Then, well, we are using passwords again.  
Certificates have lost most of their value by this point I think.
3) Users just don't understand this stuff yet.  In the case of a system 
failure most users will be completely lost with how to recover.
4) People are aware of the vulnerabilities of passwords and take at least some 
reasonable precautions with them.  Certificates are not infallible and people 
are not aware of how to properly protect them.

  Simplicity is golden here, as long as we don't truly compromise security.  I 
don't think passwords are necessarily a compromise of security.  At least not 
in contrast to TLS certificates (which I personally believe are a great 
technology).

On Thursday 07 September 2006 20:38, Dave Bacher wrote:
> 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
> feature.
>
> 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.
> >
> > Sincerely
> > Anders Rundgren

-- 
George Staikos
KDE Developer				http://www.kde.org/
Staikos Computing Services Inc.		http://www.staikos.net/