Subject: [http-auth] SSO with or without passwords

From: Yaron Sheffer <[email-masked]>
Date: Wed, 20 Jul 2011 23:52:06 +0300

Hi Stephen,

with the BOF (unfortunately) off, I'd like to go back to your assertion 
below.

You say you're skeptical of SSO with initial auth using passwords. But 
(as far as I know), any of the alternatives require a somewhat trusted 
computing devices to be owned by the user. E.g. a smartcard or 
smartphone holding your private key. While with passwords, I can walk up 
to a friend's computer, enter my Google password and get OpenID access 
to "anywhere".

Do you say that large ID providers are likely to give up on this feature 
(authentication *without* a personal device) in the next few years?

Thanks,
     Yaron

On 07/15/2011 10:00 PM, [email-masked] wrote:
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Fri, 15 Jul 2011 15:49:42 +0100
> From: Stephen Farrell<[email-masked]>
> To: Peter Saint-Andre<[email-masked]>
> Cc: "[email-masked]"<[email-masked]>
> Subject: Re: [http-auth] BoF goals
> Message-ID:<[email-masked]>
> Content-Type: text/plain; charset=ISO-8859-1
>
>
> AD hat off:
>
> The main problem I see with which we might try to help
> is the need for servers to store databases of passwords
> that inevitably leak out sometimes.
>
> So I'd like to see us develop something that gets rid of
> passwords entirely if possible.
>
> I also think its pointless to develop something that
> won't really be deployed and used.
>
> A similar, but not identical, goal might be to reduce the
> overall number of passwords, but I'd be fairly skeptical
> of SSO approaches with a password for the initial auth.
>
> S.
>

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 20 Jul 2011 22:16:14 +0100

Hiya,

On 20/07/11 21:52, Yaron Sheffer wrote:
> You say you're skeptical of SSO with initial auth using passwords. 

Not in an absolute sense. I'm skeptical that SSO with initial
passwords is the right answer everywhere all the time. I've no
problem that some people might disagree nor that they work on that.
Basically, we've had that technology for a long time and its
not addressed the problem I see as the priority. Again, others
may have different priorities.

> But

True. However, I would suspect that fewer and fewer people
will want to enter passwords into kiosks or equivalent over time,
and properly so. If we can get a scheme deployed as I'd like to
see, then I'd hope that that use-case would fade away.

> (authentication *without* a personal device) in the next few years?

No I don't. But neither do I want us to end up with a technology
that only makes sense with "large ID providers."

S.

---

From: Nico Williams <[email-masked]>
Date: Wed, 20 Jul 2011 16:21:32 -0500

> with the BOF (unfortunately) off, I'd like to go back to your assertion

I second both sentiments.

First, I think we'll need passwords for a long time yet.  This doesn't
scare me.  Augmented ZKPPs with memory-hard PBKDFs and SSO (which
enables stronger password policies because the user gets to get by
with fewer passwords to remember) would be a very strong method of
using passwords -- it can't be strong enough because in the event of a
password verifier DB compromise users will have to change their
passwords, and an estimate of off-line dictionary attack success rate
will have to inform any grace period for password changes to be easy.

Second, most cryptographic authentication protocol mechanisms'
fundamental credentials will be subject to both of: a) strong
constructions (e.g., large randomly-generated passwords stored in
password wallets), b) password-based acquisition (e.g., SACRED and
online CAs for PKI).

Properties (a) and (b) tell me that a TLS user cert approach is not
inherently superior to options such as, for example, ABFAB WG's
mechanism.  Nor are any of those other options inherently superior to
user certs, though they might well be superior to using TLS for user
authentication.

One mechanism might turn out to be universally (or close enough) good
enough that we should pick just that one.  I doubt this, but I don't
reject this possibility out of hand.  I do think it's too soon to
reach a conclusion about that, but also we may have to reach a
conclusion about that soon.

It is because I doubt the feasibility of one mechanism being
universally sufficient that I prefer a pluggable approach.

Nico
--

---

From: Yoav Nir <[email-masked]>
Date: Thu, 21 Jul 2011 09:03:01 +0300

Hi

I actually don't like the direction this thread is going. It looks to me like user certificates all over again.

Both Nico and Yaron are talking about solutions that involve a third party to the authentication. This could be keys stored on a device such as a phone, or stored on some cloud-based service, but it's a third party, and it adds complexity to any solution. It completely fails if my password wallet is inaccessible, and regardless of the technology this is going to happen.

The beauty of passwords is that they're always with me. Wherever I find any browser that's connected to the Internet, I can log in to gmail whether I have my phone with me or not, and whether the cloud-based wallet service is online or "experiencing technical difficulty".

Weak passwords and overly re-used passwords are a real problem, and it should be solved, but we should not lose sight of the fact that the convenience of user-remembered passwords is such a huge advantage, that they are here to stay for the foreseeable future.

IMO the issue that the group needs to deal with now is that the only user authentication method defined for HTTP is to send the password to the server. We know this can be fixed in protocol (whether HTML, HTTP, or TLS) and maybe, just maybe we can do it in such a way that web designers actually use it. This is what I think the (future) group should be dealing with first.

The issue of getting better passwords through RNGs and storing and accessing them through fancy cryptography is orthogonal, and the failure of OpenID makes me pessimistic about it. 

Yoav

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 21 Jul 2011 08:28:34 +0100

Hi Yoav,

> The beauty of passwords is that they're always with me. Wherever I find any browser that's connected to the Internet, I can log in to gmail whether I have my phone with me or not, and whether the c…

Up to the limit of your memory that is. Last time I counted a few
years ago I had about 60 passwords varying from important to
not-quite trivial and an uncounted number of trivial ones. Of those
I remembered about 20.

I'd also note that the most likely browser to work for an awful
lot of people is on their phone. That's a change from 10 years
ago.

> Weak passwords and overly re-used passwords are a real problem, and it should be solved, but we should not lose sight of the fact that the convenience of user-remembered passwords is such a huge ad…

User-chosen passwords that need to be remembered will be
weak. I can't see a way around that. (Passwords policies
won't solve it.)

> IMO the issue that the group needs to deal with now is that the only user authentication method defined for HTTP is to send the password to the server. We know this can be fixed in protocol (whethe…

But the BIG problem with passwords is that the databases
get stolen and passwords leak out in the millions, affecting
other sites with those same users to an unknown extent.
That won't be solved via changes in how passwords are
handled in protocols, even though those changes are well
worthwhile making. (ZKPP do help but don't fix all
problems.)

S.

> _______________________________________________
> http-auth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/http-auth
>

---

From: Yoav Nir <[email-masked]>
Date: Thu, 21 Jul 2011 11:15:55 +0300

On 7/21/11 10:28 AM, "Stephen Farrell" <[email-masked]> wrote:

>> The beauty of passwords is that they're always with me. Wherever I find
>>any browser that's connected to the Internet, I can log in to gmail
>>whether I have my phone with me or not, and whether the cloud-based
>>wallet service is online or "experiencing technical difficulty".
>

Only for those who browse the Internet with a phone. Not that many despite
the hype:
http://gs.statcounter.com/#mobile_vs_desktop-ww-monthly-201104-201106-bar

Most browsing is done with a computer. Counting on your phone to keep or
access your passwords is risky because phones can be lost, forgotten,
stolen, or broken. I've done two of these with my phone in the last month.

>
>> Weak passwords and overly re-used passwords are a real problem, and it
>>should be solved, but we should not lose sight of the fact that the
>>convenience of user-remembered passwords is such a huge advantage, that
>>they are here to stay for the foreseeable future.
>

Yes, they will. But they're so convenient that we're stuck with them
anyway. Might as well make presenting them to the server more secure.

>
>> IMO the issue that the group needs to deal with now is that the only
>>user authentication method defined for HTTP is to send the password to
>>the server. We know this can be fixed in protocol (whether HTML, HTTP,
>>or TLS) and maybe, just maybe we can do it in such a way that web
>>designers actually use it. This is what I think the (future) group
>>should be dealing with first.
>

I agree that something like OpenID would have been great. So are user
certificates. The market voted against both.

---

From: Yaron Sheffer <[email-masked]>
Date: Thu, 21 Jul 2011 12:42:15 +0300

Hi Yoav,

why do you keep saying that OpenID has failed? Do you have a reference 
for that? While people are not using the OpenID *brand*, they are using 
the standard. Take a look at the semi-transparent band at the bottom of 
http://openid.net/. Or try to login to e.g. Flickr.

Thanks,
     Yaron

On 07/21/2011 11:15 AM, Yoav Nir wrote:
>
> On 7/21/11 10:28 AM, "Stephen Farrell"<[email-masked]>  wrote:
>
>> Hi Yoav,
>>

---

From: Yoav Nir <[email-masked]>
Date: Thu, 21 Jul 2011 13:17:36 +0300

>http://openid.net/. Or try to login to e.g. Flickr.

Just did. I can login with a Yahoo! ID, and also allows me to log in with
Facebook or Google

Tried Facebook, and I get a page where Yahoo! (not Flickr, and I don't
care that they own Flickr) asks for permission to do lots of things on
Facebook. This is not OpenID.

For Google, I get a message saying "Yahoo! is asking for some information
from your Google Account..."  Kind of cryptic, but I guess this is OpenID.
So how many people are actually using this rather than creating new
accounts everywhere?  I don't have any statistics, but I'm guessing most
people have a different password for every site.

---

From: Tim <[email-masked]>
Date: Thu, 21 Jul 2011 08:57:32 -0700

> should be dealing with first.

I agree with this.  

While I would love to see seemless integration of client certificates
in web applications, I just can't see how passwords will go away until
there is truly a universal way to use your certificates no matter
where you are (think: chip implanted on body).

Right now, if users forget their passwords, what do web sites do?
They send a new password via email after may be asking users to type
in poorly-chosen answers to questions about themselves.  I find this
design really weak and in many cases the implementations of these
forgotten password systems are very unsafe.

Perhaps in the future, web sites could ask users to install a client
certificate and use it for most sessions, but fall back on a
user-chosen password (with the usual complexity requirements) in the
event they don't have their certificate in hand.  This seems to me
like a step up from what we're currently doing.  So even in a world
where certificates are used in most cases, password authentication
still needs to be there.

I don't think we should take on too much.  I think it is better to
build standards that are simple, versatile building blocks that can be
reused in multiple contexts.  Keeping new systems simple reduces
barriers to adoption.  So I agree we should stick with improving the
state of password authentication, while keeping in mind the direction
things ought to be headed.

tim

---

From: Nico Williams <[email-masked]>
Date: Thu, 21 Jul 2011 11:02:43 -0500

> Both Nico and Yaron are talking about solutions that involve a third party to the authentication. This could be keys stored on a device such as a phone, or stored on some cloud-based service, but i…

Actually, I'm not talking about trusted third parties as a necessary
part of any solution.  I'm saying we need to allow for more than one
mechanism.  Some will be distributed third-party systems, some will
not be.

> The beauty of passwords is that they're always with me. Wherever I find any browser that's connected to the Internet, I can log in to gmail whether I have my phone with me or not, and whether the c…

Agreed.  And if they're too hard to remember you'll just write them
down.  And you can always get tmp ones SMSed to your phone.  Augmented
ZKPPs get us to a good level of security, but they're not essential to
this.

Nico
--

---

From: Marsh Ray <[email-masked]>
Date: Thu, 21 Jul 2011 13:48:10 -0500

On 07/21/2011 01:03 AM, Yoav Nir wrote:
> Hi
>
> I actually don't like the direction this thread is going. It looks to
> me like user certificates all over again. [...] we should not lose
> sight of the fact that the convenience of user-remembered passwords
> is such a huge advantage, that they are here to stay for the
> foreseeable future.

With apologies to JC, "Passwords ye will have with you always".

They're just too fundamental - they're the obvious implementation of
"something you know" for anything with a keyboard. Which is why
*everyone* uses them.

I think they're so entrenched at this point that only solutions which
build and improve upon such the established base are going to have a
chance of widespread uptake.

Now there's nothing wrong with designing a niche protocol feature as
long as you're clear in advance that that's what you're doing. But I
don't think that's the case here because there's such a huge need for a
substantial improvement in web authentication.

We'd be doing a disservice to design an ideal authentication framework
from first principles if we forget the main requirement that it's
something that people will actually use.

> Both Nico and Yaron are talking about solutions that involve a third
>  party to the authentication. This could be keys stored on a device
> such as a phone, or stored on some cloud-based service, but it's a
> third party, and it adds complexity to any solution.

[disclaimer] I work for a third-party authentication provider (PhoneFactor).

Introducing a third-party *requirement* into the protocol will be a big
obstacle for many (if not most) sites. Third-party relationships get
formed at the business level with (literal) handshakes, signatures,
auditing, etc. Business people/C?Os understand this type of dependency
quite well and rightly insist on being the ones to drive its adoption.
It's not as easy a sell (internally, by the guys who work directly on
site security) as a pure technical feature.

On the other hand, a protocol feature that provided better integration
with third-party auth providers (particularly second factor solutions
like the one I work on) could be a big win. There is a large and growing
number of industries being pushed to adopt 2FA by regulation and
informal standards of due care. 2FA has some special requirements that
are not necessarily addressed by some third-party auth schemes. For
example, whereas some schemes seem to poll multiple providers and
succeed the auth if *any* provider allows it, a second-factor provider
needs an absolutely reliable way to retroactively deny the auth after a
preliminary primary auth success.

If the protocol feature specifically enabled this integration you would
have 2FA providers driving its deployment.

>  user authentication method defined for HTTP is to send the password
>  to the server.

Well there's also digest and MS integrated auth and TLS client certs,
which I think does not make your point any less valid.

> We know this can be fixed in protocol (whether HTML, HTTP, or TLS)
> and maybe, just maybe we can do it in such a way that web designers
> actually use it. This is what I think the (future) group should be
> dealing with first.

Maybe somebody ought to ask the web designers how we can help them?
Certainly many feel like the security stuff is not their favorite part
of the trade and would jump at the opportunity to get some professional
protocol support.

> The issue of getting better passwords through RNGs and storing and
> accessing them through fancy cryptography is orthogonal, and the
> failure of OpenID makes me pessimistic about it.

We've all seen crypto-nerds go off the deep end fantasizing that certain
mathematical properties will translate into real world security. I know
I've been guilty of it myself. We need to be careful about it.

Nevertheless, we shouldn't be so conservative that we shy away from
using all the skills and tools we have available, which are actually
quite considerable. This is a really hard problem and the solution may
involve reaching farther than the previous attempts.

- Marsh