Subject: Re: [websec] [kitten] [saag] HTTP authentication: the next generation

From: Robert Sayre <[email-masked]>
Date: Wed, 5 Jan 2011 20:28:08 -0500

> Peter Saint-Andre <[email-masked]> wrote:
> 2. In 2007, Robert Sayre put together a few slides on the topic:
> http://people.mozilla.com/~sayrer/2007/auth.html

These are back on the Web, in case anyone missed them (probably not).

On Sun, Dec 12, 2010 at 5:39 PM, Roy T. Fielding <[email-masked]> wrote:
>
> Define them all and let's have a bake-off.  It has been 16 years since
> HTTP auth was taken out of our hands so that the security experts could
> define something perfect.  Zero progress so far.

Hard to disagree with this assessment.

It's pretty easy to define something better than the current HTTP
authentication mechanisms, but pretty hard to design something more
popular than forms+cookies.

I've looked at this problem a little bit, and I gather the strictly
technical security properties we're looking for are pretty well
understood. Deployment and presentation control are the tough parts.
Presentation control is actually a security trade-off--to get the
control web designers want, you have to present graphics before the
server has been authenticated. Also, I suspect it will be difficult to
deploy a new HTTP mechanism that can withstand replay and DoS attacks,
unless proxy conformance gets a lot better. So, I think those
advocating TLS-only solutions might turn out to win the day, but not
because the security properties on offer are particularly compelling.

I think the IETF might do better to focus on a smaller problem, at
first. People often use self-signed certificates with HTTP/TLS, even
though the first thing their websites ask the user to do is type a
username and password into a form. There are some well-understood ways
to make this process more secure. Why hasn't the IETF fixed this
problem? If this smaller problem has no ready solution, then the
larger issue of authentication on the entire Web seems like a tough
nut to crack.

It could be that the reasons for this lack of progress are
nontechnical. Just throwing that out there.

-- 

Robert Sayre

"I would have written a shorter letter, but I did not have the time."

---

From: Ben Laurie <[email-masked]>
Date: Thu, 6 Jan 2011 15:31:51 +0000

> larger issue of authentication on the entire Web seems like a tough

Two comments (one really being a response to Roy):

1. The IETF has fixed the problem, but no-one is using the fix - perhaps
because it is not clear that it is the fix. I speak of RFC 4279, TLS
pre-shared keys. These could be derived from a hash of the password and the
site name, for example, and thus provide secure mutual authentication
despite password reuse.

2. I have often heard (though I am not aware of hard evidence for this,
nevertheless I find it plausible) that one reason no-one has bothered to
improve HTTP auth is because no-one would use it since site owners want to
control the user experience around signin. It seems to me, therefore, that
HTTP is the wrong layer to fix the problem at - it needs to be pushed down
into HTML or Javascript so that the page can control the look, while
appropriate HTML elements or JS code can deal with the secure exchange of
data.

Of course, this still leaves the issue of trusted path: although we can
provide elements which are safe to use, even when being phished, how does
the user know those elements are actually being used, rather than simulated
so as to get hold of the underlying password?

The answer to this problem is hard, since it brings us back to taking the UI
out of the sites hands.

> nontechnical. Just throwing that out there.

If you think UI is nontechnical, then I agree.

Cheers,

Ben.

---

From: Ben Laurie <[email-masked]>
Date: Thu, 6 Jan 2011 18:16:15 +0000

On 6 January 2011 16:03, David Morris <[email-masked]> wrote:
>
>
> On Thu, 6 Jan 2011, Ben Laurie wrote:
>
> Which is only helpful if you can somehow gaurantee that the user agent
> software hasn't been compromised. Not something I'd bet on...

That's rather overstating it. It's perfectly helpful when the UA
software hasn't been compromised, which is a non-zero fraction of the
time.

When the UA s/w has been compromised I'm quite happy to fail to fix
the problem: the right answer to that is to improve the robustness of
the UA.

---

From: David Morris <[email-masked]>
Date: Thu, 6 Jan 2011 08:03:54 -0800 (PST)

---

From: Tim <[email-masked]>
Date: Thu, 6 Jan 2011 08:25:59 -0800

> appropriate HTML elements or JS code can deal with the secure exchange of

Yes, the user experience piece is definitely the biggest adoption
problem for HTTP auth, IMO.  However, I disagree that HTTP is the
wrong layer.  It has already been shown (by myself and others) that
using HTTP authentication and controlling the user experience can
largely be achieved already.  A few tweaks to browser 401 response
behavior (which doesn't require standards changes) and the ability for
servers to force a log out are all that's left to provide to make
this reliable.

As for RFC 4279, I'm not really familiar with it, but I imagine the
mechansims which allow for user experience customization right now
with HTTP auth could easily be extended to any TLS authentication
mechansim.  The only requirement there would be to add some simple
language allowing for this behavior in [1].  That is, allow
XMLHttpRequest objects to hand the credentials they already accept off
to the TLS layer, either for RFC 4279 or for SRP/TLS.  

> The answer to this problem is hard, since it brings us back to taking the UI

Yes, so what I've outlined above and elsewhere is a relatively simple
transition path to allow adoption of better authentication standards
with customizable user interfaces.  But those are problematic by
design.  However, I'd assert that moving web applications off of
cookies to some lower-layer mechanism is going to be a required first
step in order to provide authentication prompts that are part of the
browser, for those who need that security.

tim

1. http://www.w3.org/TR/XMLHttpRequest/

---

From: der Mouse <[email-masked]>
Date: Thu, 6 Jan 2011 13:35:40 -0500 (EST)

> Look back far enough and you'll find all kinds of "electronic mail"
> services implementing the full range of peer and end user
> authentication, and sender-pays models.  There was no spam on those
> systems, or at least not enough that anyone felt like they needed a
> word for it.

There was basically no spam on open-Internet SMTP mail either, at the
time.  Certainly "no spam" by today's standards.

> Guess why we use the one we use today.

At the time, the services you deride weren't providing a significant
value-add.

Today?  They would be.  Perhaps not enough to make up for their costs;
probably not, in fact, or there'd be businesses arising in that space.

As a side note, it's interesting to see how well the early Internet
designers built; their systems are routinely being stressed several
orders of magnitude beyond what they were designed for, and are holding
up remarkably well.  The postal system did collapse when it started
suffering from spam; that's why the paper chain mail is actually
illegal in many jurisdictions - it took down the postal system, once
upon a time.  The telphone system would collapse if phone spam
outnumbered real calls by 10, 25, 100 to 1.  (Actually, in a sense they
already do.  I have a fax line set up, and get dozens of fax spams for
every real fax.  I've had to start adapting and applying my email spam
fighting techniques there....)

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		[email-masked]
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

---

From: Marsh Ray <[email-masked]>
Date: Thu, 06 Jan 2011 13:51:53 -0600

> At the time, the services you deride weren't providing a significant

I wasn't so much deriding them but saying there were points all over the 
trade-off curve and the market voted with its feet. Unambiguously.

Of course, the marketing creeps followed.

> probably not, in fact, or there'd be businesses arising in that space.

There are plenty. It's a commoditized low-margin business these days. 
But the network infrastructure costs are not nearly the biggest cost 
once you factor in things like end-user support.
E.g. http://www.google.com/search?q=hosted+vpn

It occurred to me last night that one might recreate the good old days 
of the Internet with a VPN which allowed access to the good old folks 
who were on it back then. Sounds a little crass and elitist now that I 
propose it out loud.

But imagine a global authenticated VPN where the only reason you could 
be banned is for spamming? Or one where you had to be at a university CS 
department? Or a whole set of overlapping criteria and you could choose 
what the membership criteria for your own view of the network?

Your own personal Virtual Public Internet.

> up remarkably well.

It is amazing, isn't it?

> The postal system did collapse when it started
> upon a time.

Nice.

> The telphone system would collapse if phone spam

We get so many unsolicited calls from telemarketers and robot dialers at 
home we don't answer the phone unless we recognize the caller ID. 
Sometimes family calling from roaming cell phones show up as 
'unidentified caller' and we mistakenly don't answer. How much more 
broken can it be?

- Marsh

---

From: [email-masked]
Date: Thu, 6 Jan 2011 13:35:56 -0800

On Wed, Dec 22, 2010 at 02:08:38AM +0000, Phillip Hallam-Baker wrote:
> Raw public keys work less well than people think here.
> 
> A public key identifies a device, never a person. To make a binding to a
> person you need infrastructure like I am describing here.

If a human being can't remember the public key (and I'm sure most of
us cannot), the human being must augment his or her memory by using
some kind of external storage device.  This is the way things must
inevitably go; there is just not enough entropy in a memorized
password to prevent anything but online attacks with a velocity check,
or something used in a ZKP.  And as bandwidth goes up, that space may
also become too small by comparison.

http://www.subspacefield.org/security/security_concepts/index.html#tth_sEc36.5

If the human being chooses to use a different password or public key
on different devices, or the same one on multiple devices, that is up
to them.  For example, some people keep SSH keys on a flash drive they
carry around with them; while it may be read into the device, it is hard
to say that it actually identifies the computing device.

Perhaps it is more useful to reverse the anthropism, and say that
human beings are such lousy, unreliable computing, networking, and
storage devices that they cannot securely authenticate themselves.  As
such, as cryptographers, we are concerned with agents, and that
passwords are a throwback, and should only be used to
identify/authenticate a human to his more capable agent/proxy/device:

http://www.subspacefield.org/security/security_concepts/index.html#tth_sEc10.6

Anyway, back to the matter at hand; keys.  In my experience, I've only
seen key-means-device in IPSec.  It seems that network security tended to
ignore users and focus on devices (nodes):

http://www.subspacefield.org/security/security_concepts/index.html#tth_sEc10.1

OpenVPN has traditionally worked this way; you install in
/etc/openvpn, so it is per-device.  But lately, Ubuntu has moved
towards having the user start it manually via NetworkManager, and the
openvpn keys/certs are usually in your home directory, making the
client side per-user.  By putting them on a flash drive, you have keys
that can move with the user between devices.

Along this hybrid approach, it may well be the case that a device may
have a key, and a user a key; for example, SSH has host keys on the
server side and per-user identities on the client side.  SSL works
more-or-less the same way when client certs are involved.

GPG tends to be key-per-person, but I suppose it can also be installed
passwordless on a pseudo-user account, in which case it's hard to
argue it really identifies a person, and more resembles the hybrid
approach mentioned above.

But this describes intent of identification; the issues are more
complex:

If all systems were only ever used by a single user, then we'd only
need key-per-device.

If we allow a single user to have multiple devices, we would then need
a many-to-one mapping of keys to identities, so that a user could have
multiple devices (SSH keys illustrate this point; many keys may get me
into my shell account).

Multiuser systems mean we must have keys for multiple users entered
into the same device.  The device is supposed to not misuse these
keys, and only use them on behalf of the appropriate user.  We SAY
that the key identifies the user, but really we mean it identifies the
device, and the device maps that to a single user, hopefully (by
example, a multi-user Unix system may have many SSH keys on it, stored
for many people, but if it operates securely, this is not semantically
different than many single-user devices).

However, if this security is broken, anyone in control of that system
is in control of my key; then the idea of it identifying me is lost.

Similarly, if someone sees or guesses my password, it no longer
identifies me uniquely.

IOW: The key identifies whatever has use of it, and that is almost
never a human being alone, since we do not speak TCP/IP.

In general, because of this agent-is-me problem, I try to avoid having
the same key used with multiple devices.  That is, I either have the
key identifying a (device) or a (device, person).  That way if the
device is compromised, the key can be revoked without affecting me on
other devices.  But current systems which assume the key identifies me
(e.g.  web passwords) do not really facilitate this.  Similarly, I
would like to know from where a key was stolen, but if I have the same
key in several places, I cannot tell.

I think the future will be humans only remembering a key or set of
keys that identify them to physically proximate devices; they should
not be identifying themselves to remote systems directly, ever, ever,
ever.  Users of password safe who do not know their own
randomly-generated web passwords know what I mean.

Perhaps we need secure key management devices with some sort of
contact interface - you select an identity on the device, and then
touch it to the system in question.

I didn't put this on http-auth since it's not strictly about HTTP
authentication, but rather key management.

I've been meaning to do a presentation on key-management, and this is a
great idea for me to add into it.  Thanks for bringing it up.

You can find my other presentations here, if you're interested:
http://www.subspacefield.org/
-- 
Good code works on most inputs; correct code works on all inputs.
My emails do not have attachments; it's a digital signature that your mail
program doesn't understand. | http://www.subspacefield.org/~travis/ 
If you are a spammer, please email [email-masked] to get blacklisted.

---

From: Ben Laurie <[email-masked]>
Date: Fri, 7 Jan 2011 12:14:32 +0000

On 7 January 2011 08:24, Yaron Sheffer <[email-masked]> wrote:
> [Culling down the mailing lists]
>
> Hi Ben,
>
> No, RFC 4279 should not be used with (a hash of) human-memorable passwords,
> because it would be vulnerable to dictionary attacks. See
> http://tools.ietf.org/html/rfc4279#section-7.2. SRP, EKE and similar schemes
> should be used instead.

Fair point, though there seem to be at least political barriers to
using SRP, and EKE and friends have other issues.

>
> Thanks,
>        Yaron
>
> On 01/06/2011 05:31 PM, Ben Laurie wrote:
> [...]
>
>>
>>
>> pre-shared keys. These could be derived from a hash of the password and
>> the site name, for example, and thus provide secure mutual
>> authentication despite password reuse.
>>
> [...]
>

---

From: Yaron Sheffer <[email-masked]>
Date: Fri, 07 Jan 2011 10:24:21 +0200

Hi Ben,

No, RFC 4279 should not be used with (a hash of) human-memorable 
passwords, because it would be vulnerable to dictionary attacks. See 
http://tools.ietf.org/html/rfc4279#section-7.2. SRP, EKE and similar 
schemes should be used instead.

Thanks,
	Yaron

[...]

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 07 Jan 2011 12:57:29 +0100

One way to mitigate the dictionary attack problem is to do PBKDF#2
processing of the password before it hits TLS-PSK.

However I agree that TLS-SRP have superior properties, and it is widely
implemented.  There is no practical reason to prefer TLS-PSK over
TLS-PSK for password-based TLS authentication.  One issue is that RFC
5054 is Informational rather than Standards Track (same issue as for
TLS-OpenPGP), which is due to political reasons.

/Simon

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 07 Jan 2011 15:29:40 +0100

The initial paper contains a security analysis with some reduction-style
arguments:

http://srp.stanford.edu/ndss.html#SECTION00040000000000000000

As with any crypto document from that time, it will lack in how the
assumptions are stated and the reductions are made.  That considered, is
there something in particular that you think is missing in there?

We can fix the problem with lack of review by implementing and deploying
the protocol, then certainly researchers are bound to focus on it. ;-)

/Simon

Yaron Sheffer <[email-masked]> writes:

> Another issue is that SRP (as opposed to other protocols in this
> space) is not provably secure, and in fact has had relatively little
> cryptographic review, AFAIK. I would be glad to be proven wrong on the
> second point.
>
> Thanks,
> 	Yaron
>
> On 01/07/2011 01:57 PM, Simon Josefsson wrote:
>> Yaron Sheffer<[email-masked]>  writes:
>>

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 07 Jan 2011 17:54:46 +0100

Yaron Sheffer <[email-masked]> writes:

> - I am not a cryptographer, so I am treading on extremely thin ice here.
>
> - SRP is certainly better than using PSK with passwords, which is
> *definitely* vulnerable to dictionary attacks.

One final addition here, the situation for PSK depends on the flavour
and whether you are talking about active or passive attackers.  The
statement is true for plain PSK, but less so for DHE_PSK and RSA_PSK.
Section 7.2 of 4279:

   For the PSK ciphersuites, an attacker can get the information
   required for an off-line attack by eavesdropping on a TLS handshake,
   or by getting a valid client to attempt connection with the attacker
   (by tricking the client to connect to the wrong address, or by
   intercepting a connection attempt to the correct address, for
   instance).

   For the DHE_PSK ciphersuites, an attacker can obtain the information
   by getting a valid client to attempt connection with the attacker.
   Passive eavesdropping alone is not sufficient.

   For the RSA_PSK ciphersuites, only the server (authenticated using
   RSA and certificates) can obtain sufficient information for an
   off-line attack.

/Simon

> - That said, I have done my little bit of due diligence (talked to the
> author of SRP and to several cryptographers who've played with some of
> these schemes). Personally, I would rather use a protocol that's been
> formally proven (PACE, AugPAKE, other descendants of EKE) or has had
> real solid cryptographic review (the original EKE). Again, I would be
> happy to be proven wrong on this.
>
> - Even if we start with a mathematically perfect protocol, we are
> bound to make design and engineering mistakes. And Marsh and his like
> will happily poke holes into these implementations :-) But I'd like to
> avoid compounding the risk with cryptographically unsound protocols.
>
> Thanks,
> 	Yaron
>
> On 01/07/2011 04:29 PM, Simon Josefsson wrote:
> _______________________________________________
> Kitten mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/kitten

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sat, 8 Jan 2011 11:07:38 -0500

I think that Ben is right that we are solving the wrong problem.

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!

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.

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

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.

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.

Client authenticates to authentication service using any protocol they both
support.

This is quite simple to implement, just stick a list of supported auth
services in the DNS.

We can re-use all those existing auth protocols that work (SAML would be a
good choice but we don't need to be overly restrictive here.)

HTTP carries a standardized, non-linkable auth token

I have some ideas on how we could modify DIGEST to do this. DIGEST would not
be problematic if the password had 128 bits of ergodicity and we upgraded
the digest function.

The reason for re-using DIGEST here would be to avoid patent encumbrances. I
considered the issue of linkability at great length when writing the
original DIGEST design.

At the moment I am focused on getting the foundation laid. But I will try to
come up with a full proposal before Prague.

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).

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.

Devices get lost. Devices get stolen. 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)

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.

> pre-shared keys. These could be derived from a hash of the password and
the
> saag mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/saag
>
>

-- 
Website: http://hallambaker.com/

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sat, 8 Jan 2011 11:21:42 -0500

> the problem: the right answer to that is to improve the robustness of

+1

If the UA is stuffed then the user is totally and utterly stuffed anyway.

In particular if the UA is stuffed then a forms based experience is just as
stuffed. If we are going to hypothecate attack models people have to be
willing to apply them to their preferred solution too.

The sensible approach is to work out how to stop the user from being stuffed
e.g.

 * Comodo's free Anti-Virus with Default Deny Protection (TM)
 * Use code signing + trustworthy computing
 * Use a restricted browser

Now I have a lot of ideas on how we can tackle these, but they are not
relevant to this debate.

I do however have a different take on the UI issue.

HTML forms did have an advantage over the pathetic UI that browsers provided
for BASIC and DIGEST (most don't even tell the user which is in use).

But a federated auth scheme supported at the HTTP level could be simpler
still. Instead of the user having to register for each site, they register
once. Instead of the user having to log in to each site they log in once per
session. Instead of the site having to manage lost passwords and forgotten
accounts because the user has hundreds, this problem does not exist.

It is a user interface crisis that is driving this need in my view.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sat, 8 Jan 2011 12:52:45 -0500

OAUTH and Webfinger are both pretty much as good as you can expect to
achieve if you decide at the start that you are not going to modify the
infrastructure.

But that decision limits what you can expect to achieve.

A particular problem with OAuth is that you can only use the identity
providers that are supported by the particular site. So I had to use my
Twitter account to play spymaster. And when Twitter got shirty and started
blocking other players accounts they lost their game account and their
twitter account at the same time.

There are people who think I should get a facebook account just so that I
can use their application. Not happening.

As for WebFinger, it works, but not nearly as well as a clean DNS scheme.
DNS is designed to address this problem, HTTP is not. And solving the
problem with HTTP requires us to have a scheme that involves DNS + HTTP +
SSL + PKIX which is rather a lot of moving parts and to make matters work
some those parts are not just moving, they are changing.

I think it is a very good idea to look at WebFinger and OAuth and see how to
realize these approaches direct in the infrastructure. But they should be
seen as starting points, not ends.

On Sat, Jan 8, 2011 at 12:37 PM, Blaine Cook <[email-masked]> wrote:

> Two points:
>
> 1. In this entire thread, no-one has mentioned OAuth. Maybe y'all
> don't like it, but it's used to authenticate more HTTP requests by
> volume and users than everything-except-cookies combined. You may want
> to consider the design of OAuth when proceeding with these
> discussions, rather than the laundry list of [completely] failed
> protocols.
>
> 2. With respect to federated auth, especially using email address-like
> identifiers, there has been a bevy of (deployed) work in this regard.
> The effort is called webfinger, and is worth a look. Instead of DNS,
> we use host-meta based HTTP lookups to dereference the identifiers.
> Many diaspora and status.net installs are using it today, and there
> are several proposals towards building a security & privacy
> infrastructure on top of webfinger (webid is one such proposal whose
> incorporation of client-side TLS certificates in a browser context
> makes me very weary of its potential for success).
>
> b.
>
> On 8 January 2011 08:21, Phillip Hallam-Baker <[email-masked]> wrote:
> > apps-discuss mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/apps-discuss
> >
> >
>

---

From: Yaron Sheffer <[email-masked]>
Date: Fri, 07 Jan 2011 14:57:05 +0200

Another issue is that SRP (as opposed to other protocols in this space) 
is not provably secure, and in fact has had relatively little 
cryptographic review, AFAIK. I would be glad to be proven wrong on the 
second point.

Thanks,
	Yaron

---

From: Yaron Sheffer <[email-masked]>
Date: Fri, 07 Jan 2011 18:05:09 +0200

- Even if we start with a mathematically perfect protocol, we are bound 
to make design and engineering mistakes. And Marsh and his like will 
happily poke holes into these implementations :-) But I'd like to avoid 
compounding the risk with cryptographically unsound protocols.

Thanks,
	Yaron

---

From: Tim <[email-masked]>
Date: Fri, 7 Jan 2011 09:42:13 -0800

>    RSA and certificates) can obtain sufficient information for an

In the general case, I don't think it is useful to differentiate
between passive and active attackers.  Performing man-in-the-middle
attacks is no more difficult (in a big-O sense) than performing
passive attacks.  In almost every modern network, these attacks
require the same level of network access.

Just a pet peeve of mine.

cheers,
tim

---

From: Blaine Cook <[email-masked]>
Date: Sat, 8 Jan 2011 09:37:00 -0800

Two points:

b.

---

From: "Zed A. Shaw" <[email-masked]>
Date: Sat, 8 Jan 2011 11:49:52 -0800

> discussions, rather than the laundry list of [completely] failed

I don't normally respond, just being a lurker, but this statement is
competely wrong Blaine.  OAuth may be used for more requests, but not
more sites.  It's used on a tiny number of sites, with OpenID being used
on way many more, and even then, not nowhere near the number of websites
that form based authentication and browser authentication methods.

Don't equate twitter having a ton of traffic to OAuth being some kind of
raving success, and sure as hell don't evaluate the technical merits of
something by its popularity.

> makes me very weary of its potential for success).

While I agree that TLS client side isn't going to work, none of the
proposed authentication methods will work without a change to browsers
to support a way for two websites to establish a session in the browser.
If that feature existed you would cut down on a lot of the complexity of
things like OpenID and OAuth.

-- 
Zed A. Shaw
http://zedshaw.com/

---

From: Marsh Ray <[email-masked]>
Date: Sat, 08 Jan 2011 15:32:59 -0600

> 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).

> 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.

>     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?

>     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

> 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.
>
> 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)'.

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

---

From: Blaine Cook <[email-masked]>
Date: Sat, 8 Jan 2011 17:29:29 -0800

> something by its popularity.

Agreed - though, facebook is also using oauth-based (not 1.0, but
essentially the same approach) logins, and there are a number of other
sites that do provide oauth-based login infrastructure.

Moreover, the nudge towards oauth is intended with the movement
towards a new auth infrastructure in mind. We'd need some kind of
discovery / negotiation mechanism on top to make it not the
one-or-two-companies-own-the-web play that login-over-oauth is now.
(c.f. OpenID Connect).

b.

> things like OpenID and OAuth.

Again, agreed. ;-)

for the record, I don't think that OAuth itself is a suitable
replacement for HTTP authorisation, but wanted to stir the pot,
especially away from overwrought technical solutions that don't
actually solve anyone's needs.

b.

---

From: Ben Laurie <[email-masked]>
Date: Sun, 9 Jan 2011 13:44:12 +0000

> actually solve anyone's needs.

Towards ones that are ripe for phishing and have no privacy
protections? I don't believe that's a good direction.

---

From: Blaine Cook <[email-masked]>
Date: Sun, 9 Jan 2011 08:40:54 -0800

> protections? I don't believe that's a good direction.

*shrug* If the alternative is Facebook handling everyone's logins, it
can't get much worse, can it?

b.

---

From: John C Klensin <[email-masked]>
Date: Sun, 09 Jan 2011 13:22:04 -0500

--On Saturday, January 08, 2011 15:32 -0600 Marsh Ray
<[email-masked]> wrote:

> 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).
>...

Well, actually, I think this is constructive, useful, and rather
nicely describes the other side of the problem.  

I would add that one important variation on "Person = Identity =
Email address" has historically involved the use of
subaddresses.  Not only do they help considerably with mail
management (pretty much their original purpose) but they provide
an additional  (weak but convenient) measure against email fraud
and identify theft attempts (if I know that mail from my bank is
going to be addressed to "[email-masked]" because that
is the only address they have, then it is pretty clear where
mail that supposedly comes from them but is addressed to
"[email-masked]" should be routed.   Obviously,
if an address that is used for only one vendor or correspondent
gets into the hands of a spammer, it is lots easier to fix that
problem as well.  

Address-per-correspondent also makes password-per-correspondent
much easier too.

Lots of web sites and providers have been really resistant to
that approach.  I had assumed before this that the problem was
just stupidity, but parts of your comments could be expanded to
lead to the inference that having me use more than one address
is not in their interests.    Whatever becomes of that tradeoff,
the IETF should not, IMO, be doing things that encourage them in
directions that reduce our privacy and ability to control our
identities. 

>...
> 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.
> 
>...

exactly.  with the emphasis on "at least"

>...
> 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.

Indeed.  In all of the really significant cases, probably the
latter.  If I had a nickel for every sticky note with a password
(sometimes slightly-disguised) stuck to a screen...  But those
notes are precisely a workaround for "you have to change your
password frequently, you can't share passwords between systems,
and we will insist by various means that you passwords are
strong and that a given password is not obviously derivable from
its predecessors" policies.

>...

   john

---

From: Ben Laurie <[email-masked]>
Date: Sun, 9 Jan 2011 19:21:34 +0000

On 9 January 2011 18:32, Zed A. Shaw <[email-masked]> wrote:
> On Sun, Jan 09, 2011 at 01:44:12PM +0000, Ben Laurie wrote:
> Ripe for phishing?  I must have missed a whole conversation in all this
> cross posting, because last I checked none of the proposed solutions
> prevent phishing.
>
> If you can phish one site you can phish another.  It's not the sites or
> the protocol that causes phishing, or whether you've got a billion
> redirects or diffie-helman to the hilt.  OpenID or Oauth or
> plain-old-form-auth don't prevent or cause phishing.
>
> What causes phishing is users have no idea that two websites are
> different.

Whilst I do not disagree with this claim, you are wrong. There are
protocols which effectively prevent phishing - so long as password
entry is done in an unspoofable UI.

I am sure that you will respond that UI can be spoofed as easily as a
website can be, and I'm almost ready to agree with that, given that we
still don't have a good answer to that, however, my one small ray of
hope in this regard is that there's only one UI we need to make
unspoofable as opposed to a million websites. And, what's more, we
don't really need to invoke it every time a user logs in to a website
- really what we want is for the user to authenticate to their device
and have the device handle the rest.

OpenID and OAuth are particularly nasty, even by today's standards,
because they provide a trivial route for the phisher to do a perfect
MitM attack on the IdP.

---

From: "Zed A. Shaw" <[email-masked]>
Date: Sun, 9 Jan 2011 12:16:27 -0800

> entry is done in an unspoofable UI.

Alright, to avoid any "violent agreement", can you point me at any
documentation you have on your proposed solution?

-- 
Zed A. Shaw
http://zedshaw.com/

---

From: Marsh Ray <[email-masked]>
Date: Sun, 09 Jan 2011 15:07:40 -0600

> documentation you have on your proposed solution?

As you pointed out Zed, phishing isn't something that happens to a
protocol or an application - it's something the user decides to do.

Phishing can be said to have been prevented only when the user can be
relied upon to refuse to enter his password into an insecure box.

Now there may be some useful mitigations at the app or protocol level. 
For example, my bank asks for my username and then shows me a familiar 
picture (e.g., a rocking horse) that is supposed to prevent phishing. 
This stops phishing only in the sense that it requires the attacker to 
use a CGI proxy app rather than simple static phishing site.

For some sites that probably cuts down on the rate of phishing attacks 
quite a bit. But something so easy to bypass is likely to depend on a 
steady supply of easier targets keeping the attackers busy. If I wanted 
that kind of security for my car, I should try to convince everyone else 
in town to leave theirs unlocked with the keys in the ignition. I don't 
think it will be useful against a determined, targeted attack.

On 01/09/2011 02:13 PM, Peter Saint-Andre wrote:
>
> And please start cc'ing only [email-masked], not all the other
> lists.

You're trying to convince users not to do something that the interface 
begs them to do, like hit 'reply all', or trying out every password they 
know. It's not part of the protocol.

- Marsh

---

From: Theodore Tso <[email-masked]>
Date: Thu, 13 Jan 2011 13:27:10 -0500

On Jan 8, 2011, at 11:07 AM, Phillip Hallam-Baker wrote:

> 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!
> 
> 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.

The fact that web sites, like Gawker, will screw up, is why you need to maintain different passwords at every single one.  And at least Gawker admitted that they screwed up, and told everyone to change their passwords once this came out.  Many large corporations would have tried to stonewall and claim their security is perfect or at least not publicize the security breach to their users.

Personally, I think the horse left the barn a long, long time ago, and this is not a problem we can fix today.  What I use for my non-financial accounts is the LastPass plugin, which scans HTML form pages looking for username/password form fields, and if it finds them, looks up the username/password in a database which is stored in the cloud in an encrypted fashion, and populates them into HTML form.  It also will automatically generate nice, long, random passwords for every site when you change your password, and allows you easily use long, hard-to-memorize (and thus secure) passwords that are different for every single web site.

The only reason why I don't use it for my financial web sites is because it's a closed source browser plugin, so I can't audit it to make sure it's not stashing away passwords and publishing them to the manufacturer via some covert channel.  But if they want to steal my Financial Times and Economists logins, hey, they can be my guest.

It may be ugly that we're dealing with this at the HTML/presentation battle, but any other solution will take years to roll out, and the issues of trust and liability which to date have doomed any large-scale PKI rollout are going to bite us here.   And in a federated scheme, the question of which federated entities a user should trust to potentially give access to *all* of their web sites is still at best a research problem.  So at least for web security, maybe the best we can do is to make things easier for the browser or browser plugins to manage different accounts at hundreds of different web sites.   This may ultimately be an easier, and be a much more easily deployable, solution than some kind of federated authentication proposal.

-- Ted

---

From: Ben Laurie <[email-masked]>
Date: Fri, 14 Jan 2011 10:00:18 +0000

On 14 January 2011 02:24, Peter Gutmann <[email-masked]> wrote:
> Marsh Ray <[email-masked]> writes:
>
>>Phishing can be said to have been prevented only when the user can be relied
>>upon to refuse to enter his password into an insecure box.
>
> I think you need to phrase that more generally, "when the user can be relied
> upon to not authenticate to the wrong site", because there's more ways of
> authenticating around than just typing a string into a web form.  For example
> some password managers do site-specifc passwords, so even if you go to the
> wrong site you can't accidentally provide your credentials for the correct
> site.

That phrasing is only correct if the authentication method leaks the password...

>>picture (e.g., a rocking horse) that is supposed to prevent phishing. This
>>stops phishing only in the sense that it requires the attacker to use a CGI
>>proxy app rather than simple static phishing site.
>
> ... or display a broken-image GIF, or a message that the award-winning
> security whatsit is being upgraded and will be back soon, or ...
>
> (this is from a real-world evaluation of the (in-)effectiveness of site
> images, I can dig up the ref if required).  Site images rate more as a
> security gimmick than any real security measure.

Exactly.

---

From: Marsh Ray <[email-masked]>
Date: Fri, 14 Jan 2011 11:07:33 -0600

On 01/13/2011 08:24 PM, Peter Gutmann wrote:
> Marsh Ray<[email-masked]>  writes:
>
>> Phishing can be said to have been prevented only when the user can
>> be relied upon to refuse to enter his password into an insecure
>> box.
>
> I think you need to phrase that more generally, "when the user can be
> relied upon to not authenticate to the wrong site", because there's
> more ways of authenticating around than just typing a string into a
> web form.

I was trying to be as general as possible but still thinking in terms of 
phising for passwords.

(This conversation has bounced around a bit between "better HTTP 
password authentication don't you dare mention client certificates" and 
"open-minded discussion of login authentication methods". I'm happy to 
contribute to whatever, but we risk 
miscommunication-mistaken-for-disagreement unless we settle on the scope 
first.)

The term "authenticate to the wrong site" has completely different 
meaning depending on whether or not we're talking about 
capture-and-reuse credentials like passwords or whether or not we're 
assuming encryption which authenticates the server to the user (https).

So I was thinking of "password into insecure box" as being more general. 
Maybe the attack somehow doesn't even involve the "wrong site", maybe 
bad guy injects something into the right site instead?

> For example some password managers do site-specifc
> passwords, so even if you go to the wrong site you can't accidentally
> provide your credentials for the correct site.

OMG, I can't stand it when I type the right password (for something 
else) into the wrong box. I admit that I have not always immediately 
changed that password when I've done it into a computer I also sort-of 
trusted (but in a different scope).

> Site images rate
> more as a security gimmick than any real security measure.

It'd be interesting to know if banks get an actual reduction in the rate 
of phishing from that.

On 01/13/2011 08:33 PM, Peter Gutmann wrote:
> Phillip Hallam-Baker<[email-masked]>  writes:
>
>> Such users have asked to do business with hundreds of entities, so
>>  at least something is working right.
>
> Actually they haven't asked to to business with most of them, but
> are required to have an account for
> user-tracking/spam-defeating/who-knows-what purposes.

Yep. I guess I was counting things like Slashdot and Twitter as "doing 
business", even though it wasn't a monetary transaction. There is some 
value stored in those credentials, or at least pain-in-the butt 
potential costs to me if they were compromised for some reason.

> If browsers
> provided a basic "generate a random password just for this site"
> feature, as many password managers have been doing for years and
> years, then we could focus on the tiny fraction of sites where
> authentication really matters.

That would be convenient, but how many people back up the password 
manager in their browser? I don't, I prefer to write them down.

I use multiple computers and multiple browsers. No browser has every 
password. Encouraging them to be centralized in the browser seems less 
than ideal, since it's the browser that gets pwned more than anything else.

> Two major problems that we initially
> need to overcome are:
>
> 1. Browsers (I'm using this as a generic for "client-side software")
> treat all passwords as being equal, from your high-value banking
> one to your throwaway knitting-patterns-blog one.

Yes, I agree that's a big problem.

I don't think we should think of them as being fully-ordered on a 
dimension of 'value' however.

For example, let's say I have:

A. Password for current employer's single-sign-on Kerberos/Active 
Directory infrastructure.

B. Password I use at job-hunting website

C. Password I use for my pseudonym where I flame newbies and post 
obscene patterns on the knitting patterns blog.

My work desktop computer will most likely be backdoored by my employer. 
They may not care about C, but I care greatly that they do not find B.

I log in to the employer from a home PC or smartphone from a VPN A. I 
may have a sense of responsibility about protecting A, but apparently 
I'm looking for a new job anyway. I'm more interested that prospective 
employers don't find out about C.

 From a public internet terminal I may not care at all about accessing C 
because it doesn't seem plausible that it would associate back with my 
professional identity.

> 2. Browsers (ditto) have close to zero support for even the most
> basic password management that any number of plugins and add-ons have
> had for years (the Firefox 3.6 password manager is, AFAICT, unchanged
> since the Netscape 2.0 one from fifteen years ago).

It works sort of OK for me. But I'm only happy with it because I 
wouldn't trust it with all of my passwords regardless of how .

> If we could start to address this, and at least begin to bound the
> problem, we've made a start.  Theorising about blue-sky solutions
> isn't useful when we haven't even defined the real problem we're
> trying to solve.

Yes, let's resist the attraction of actual solutions until we have 
defined the problem to death. The possible solutions and their pros and 
cons of will usually be obvious by that point.

- Marsh