Re: [apps-discuss] [http-auth] [saag] [websec] [kitten] HTTP authentication: the next generation

[Marsh Ray <[e-mail]>]

On 01/08/2011 10:07 AM, Phillip Hallam-Baker wrote:
> I think that Ben is right that we are solving the wrong problem.

I think Ben is nearly always right. :-)

But let me toss out a different perspective. I'll try carefully and hope 
that this doesn't come across as trolling, but it is a bit contrarian 
(hopefully in a good way).

> The problem is that users are asked to maintain accounts at literally
> HUNDREDS of accounts.
>
> And some cretins, some utter morons, some bog-brained berks think it is
> reasonable to tell the user to have a different password for every one!

Such users have asked to do business with hundreds of entities, so at 
least something is working right.

The user is free to use the same password everywhere (more convenient), 
or use a different password at every site (more secure). Many users like 
to set up "domains of password re-use" among several like-sites. The 
user is free to decide the point on the trade-off that works for them.

I use a different password for everything. I write them down on blank 
business cards and keep them physically secure. I have taught some small 
children to use this scheme and they have no trouble with it. Most web 
browsers and sites remember the passwords anyway so the paper is really 
just backup.

> I can't remember the account names, the password is easy as I only had
> one (for non financial) - until those cretins at Gawker screwed up. Now
> I have to reset my password at all those places.

So you had decided on a coarse-grained scheme: financial and 
non-financial. Seems reasonable on the surface.

Say you have a dozen sites across which you share a password. These 
sites are really secure - let's estimate the probability that each one 
will be breached or compromised or you will accidentally login 
unencrypted from a public internet location is only 1 in 10 per year. 
Hey a 90% success rate isn't bad, right?

But the probability that they will all succeed is 0.9^12 = 28% over a 
year. Expect to be changing that password every few months.

In the case of "HUNDREDS of accounts", 0.9^200 = 0.000000001. Well, 
those of the sort of odds you're supposed to serve the attacker, not 
yourself.

> We have to solve the federated auth problem and it is really, really easy:

No, it borders on the impossible.

> Account Name is the RFC 821/822 email address.
>
>     This is what the Web has started to adopt of its own accord as a
>     user account identifier. It is the only one that people can remember
>     reliably.

Which is why everyone just has one email address? Come on, most people 
have several. And often they do so for a reason, it's not just that 
people get new ISPs or switch for new features all the time. I train my 
kids to lie about their names and ages when they do stuff online. They 
don't have emails.

You don't have a personal email and a work email at least?

> Authentication service is resolved via DNS service lookup
>     i.e. SRV or similar. I can show people how to fix up the issues to
>     do with use of non-canonical names.

[skipping a bunch of technical stuff]

> I know that you can achieve some of the desired authentication
> properties with public keys at the client. The problem is that our
> current use of computers has gone way beyond the one-machine-per-person
> paradigm

> On a recent trip to Europe with the family I counted that we had 10
> computers with us capable of supporting IP (3 laptops, 3 iPhones, 2
> Nintendos, 1 iPad and a kindle).

It was only a brief period in the history of computing that might have 
ever been true anyway.
Before networks "user identity" hardly mattered. Immediately after 
networks, we got heterogeneous networks. As soon as heterogeneous 
networks arrived, we got single sign-on.

I think the deeper problem today is that most people looking at the 
issue are coming from the service provider side. Their job is made 
greatly simpler if they can assume 1 user = 1 person = 1 email etc. So 
they make this assumption as much as they can get away with it.

But the reality is that people don't work that way. Historically, people 
have had multiple identities and they presented themselves differently 
to different parties. This is intentional and it's not duplicitous, its 
part of normal social interaction.

When you discuss business matters at work you give out a business card 
with a business phone number and address on it. When you meet people at 
church or school, you give people your home phone. Your home phone and 
address were the ones printed in the directory.

So the fact that "a person" has more than one "device" is not the big 
problem (that's actually sometimes a desperate solution from the 
perspective of the user). The problem for the service provider is that 
they don't want to give up the simplifying assumption (and the 
behavioral tracking it enables) that a real person represents an atomic 
unit of identity.

Aside from the brittleness of their security, this is one reason why 
centralized identity, top-down federated authentication and 
single-sign-on schemes are not a good plan for the web. They don't 
accurately model the problem domain.

These schemes originated for use in corporate and university settings 
which, at the end of the day, have all of the protected resources owned 
by a single party. The universal ritual for everyone's first day at a 
new job is the granting of a new username, password, and email identity 
for use in that specific context. So single sign-on was designed so that 
one person could be granted access to, say, the file server, email, 
printer, and maybe the phone system, all within the restricted context 
of their "employee-ness" at one specific company. Even though multiple 
systems are involved, it's still fundamentally a one-to-one relationship 
between two identities, the person-as-employee and the company-as-employer.

This doesn't map to the web with multiple persons each needing to 
control the mapping of their own multiple identities to multiple 
corporations. I don't want to pull out my US State Department-issued 
passport in order to leave a comment on some random blog or log into an 
online game. I don't want to use any of my gmail addresses for that either.

Bad things happen when you force-fit the wrong model on to the design. 
Security and privacy are always the first to go. (Somewhere I saw the 
other day somebody seriously proposing using Facebook as a centralized 
identity authority.) More subtly, people find the system harder to use, 
and overall they just don't like it or trust it as much. People won't 
use it, or they'll use it and not like it, or they won't use it as much, 
or they'll figure out a way to defeat it.

> Cardspace has some really, really great properties but they are totally
> lost when you try to make the service accessible from multiple machines
> by putting it 'in the cloud'. In fact, other than a manager, I have
> never found anyone who reven thinks they know what they mean by 'in the
> cloud' for CardSpace. I certainly have never seen an explanation I can
> understand.

Cloud is largely an experiment in making unwarranted assumptions about 
identity in the other direction: between the corporation and their devices.

> Devices get lost. Devices get stolen.

My impression is that lost and stolen devices are significant, but 
they're by far not the biggest security issue on the web.

> We don't want to encourage that so
> there needs to be something more than just a certificate based client
> auth scheme.
>
> I think we need some form of centralized (for given account) account
> management in the mix so that the user can authorize/deauthorize devices
> for use (c.f. Amazon's Kindle account management)

You're not going to create everybody's favorite web authentication 
infrastructure if it has the goal of controlling people use of their own 
devices.

> So there are basically two architectural options for using public key.
> One is to use it strictly between the client and the auth service and
> use a token like approach as discussed above. Another is for the auth
> service to issue an assertion of the form 'you can tell its fred by this
> public key (amongst others)'.
> SAML already has support for both approaches BTW.

Forget the wants of corporations and websites, they exist only because 
of their customers and users who outnumber them a millionfold. Forget 
mechanisms for now, those are simple engineering once the problem is 
stated correctly.

What do people want to do?

What would they want to do if they knew to ask for it?

How can we help them do it in the most secure way possible?

How can we give people the tools to manage their own identities and make 
their own security-convenience trade-offs in the most informed way?

Regards,

- Marsh