RE: Draft W3C TAG Finding "Passwords in the Clear" available for review

Some perspectives that might be useful here:

1) Its about giving the user a fighting chance.

This came up in Web Security Context. We realized that we were looking
at the problem from the wrong perspective. We were all trying to prevent
bad things happening to the user. This is a good goal but cannot be
achieved in one go. There is no security measure we can deploy today
that we can guarantee users will react to. Users have been trained to
ignore the security indicators for ten years. Every proposal to add
meaningful security information was being shot down with the objection
'people won't bother'.

Well lets stop worrying about the people who can't or won't help
themselves and instead focus on the users who are trying to. Lets make
the first step in improving Internet security to give the users a
fighting chance by providing an unambiguous and unspoofable security
indicator that provides a reliable indication that the user is safe.


2) Security Usability is the avoidance of baddnes, not looking for the
best.

This is a generalization of the above maxim that I arrived at while
considering the different challenge we face in security usability rather
than usability in general. The usual goal in usability engineering is to
arrive at a distinctive product that is unusually good. Only a small
proportion of engineers and designers are even capable of understanding,
let alone reaching this goal. It is an elite design process that is
going to require extensive trial and error, in particular expensive user
studies.

The objective in security usability is subtly different. Safety cannot
be a competative differentiator. Traffic lights must be red for stop and
green for go in every country. If different countries adopt different
conventions the result would be chaos. It is acceptable for Firefox3 to
have a different security interface to IE8. It is not acceptable for the
two browsers to present incompatible cognitive models of the security
process.

Testing plays a role in consumer testing of course. Before a product
receives the UL seal of approval it will be subjected to a series of
empirical tests to verify its safety. But there is much more to the
process than testing, the designs must be theoretically sound as well.
The power cord must be appropriate for the device and correctly fused.
The insulation must be correctly specified. A product that fails the
design review won't make it to the test lab.

Most security systems have design flaws that should be obvious to the
designer without the need to test. The user does not have sufficient
information to perform their tas safely, the cognitive model of the
system is incoherent (if there is a model at all), the system throws
away valuable user effort and demands the user re-enter it. I am
currently working on a 'design checklist' for security usability which I
am caling the 7 laws of security usability.


3) It is reasonable to demand that a password should never be sent
either en-clair or to an unauthenticated party

In WSC we had a discussion on the subject of mandating SSL for passwords
and there was the usual round of discussion of whether we can mandate
blogs and non-commercial Web sites to pay for a Trusted Third Party
issued SSL certificate. We didn't complete the conversation in the WG
but we did recognize that the emergence of OpenID, SAML etc. changes the
game:

* It must be possible for Web sites to authenticate users without cost
* It is entirely reasonable to expect an identity/authentication
provider to pay for a cert

This is one of the problems I have with the assumptions in the OpenID
world. I do not believe that it is either necessary or desirable for an
identity protocol to be designed to provide a low barrier to entry for
identity providers.


4) Passwords belong to users, users should decide who manages them.

Passwords are intrinsically valuable assets. Users have a limited
capacity for remembering passwords and it is inevitable and in fact
desirable for users to be able to leverage a single password at multiple
sites.

It follows therefore that any site which requires a password to be
supplied for any purpose should be required to provide protection for
that password during both the registration and the log-in processes.

Sites should stop maintaining local databases of primary usernames and
passwords. The only sites that should maintain databases of
authentication credentials are sites that are providing a federated
identity service.

I would even suggest extending the principle to financial services
sites. Today the customer typically has a single username/password that
is used for all transactions regardless of risk. A much better risk
management approach would be to separate transactions according to the
degree of risk involved, use a federated identity provider to gate
access to non-security sensitive transactions and then use a secondary
authentication technique for sensitive transactions.


Next Steps
----------

At present we are coming to something of a convergence in the industry.
It was something of a frustration to me that while I was writing The
DotCrime Manifesto (Addison Wesley available from Amazon for circa $20)

I think we are in striking distance of a convergence.


OpenID is designed within the limitations of existing systems, it is
positioned to build critical mass for federated identity. In particular
OpenID has the concept of a uniform identifier.

SAML has an extensible, secure and exhaustively reviewed architecture
but lacks the concept of a uniform identifier for identity.

CardSpace is welded into the operating system, it provides security and
usability with no compromises. As Trustworthy computing is deployed the
security offered by cardspace will continue to improve.


We are in striking distance of a grand alliance, OpenID is already SAML
friendly and Microsoft has joined the OpenID board. The only piece we
are missing at this point is to get buy in for the converged system in
IETF, W3C, OASIS etc. We need the statements of how SMTP uses this
infrastruture, how HTTP uses it, Web Services, POP3, IMAP, etc. etc.

Received on Thursday, 14 February 2008 15:31:43 UTC