Another entry in the internet security hall of shame....

Peter Gutmann pgut001 at cs.auckland.ac.nz
Wed Sep 7 03:33:01 EDT 2005


Alaric Dailey <alaricd at pengdows.com> writes:

>While I admit that PKI is flawed, I don't see anyway that PSK could used
>effectively.
>
>How are PSKs going to be shared in a secure way?
>are we talking about generating a new key for every connection?
>    if so how do you validate the key?
>    if not, how do you validate that the key hasn't been compromised by
>someone who put up a phishing site?

Gosh, I don't know.  How about the way we've already been doing it for the
past decade or so on every single passworded web site in existence, and for
another decade before that with ATM PINs.

>In my opinion, PSK has the same problems as all symmetric encryption, its
>great if you can share the secret securely, but distribution to the masses
>makes it infeasible.

Exactly, PSK's are infeasible, and all those thousands of web sites that have
successfully employed them for a decade or more are all just figments of our
imagination.  By extension, ATMs are also infeasible.

Sarcasm aside for a minute, several people have responded to the PSK thread
with the standard "passwords don't work, whine moan complain" response that
security people are expected to give whenever passwords are mentioned.  It's
all the user's fault, they should learn how to use PKI.  Well we've had ten
years of that and it seems to be making bugger-all difference in protecting
users, based on the universal success of phishing attacks.

What's happened is that security people have said "Here's our perfect
solution, PKI, and we're not budging an inch on that", the masses have said
"We can't manage anything beyond usernames and passwords and we're not budging
an inch on that", and the phishers have leaped in and filled the gap between
the two while both sides are sitting there holding their breath to see whose
face goes blue first.

The failing is in the security community.  Security practitioners (by which I
mean people who build secure systems, not ones who merely go out and
pontificate about them) have 30 years of research in authentication mechanisms
to fall back on, and yet the state-of-the-art in use today is to hand out the
plaintext password to anyone who asks for it: "Hi, I'm your bank, or Paypal,
or something, please give me your password".

Instead of using a decent (and trivial to implement) challenge-response
mutual-authentication mechanism, we're using the worst possible one there is,
the one that every security textbook warns against, while sitting back and
waiting for PKI to start working.

My mother (to use my favourite canonical non-technical user) has figured out
how to use a username and password to authenticate herself.  She hasn't, and
never will, figure out PKI, and nor will most of the rest of humanity.  The
users have amply demonstrated to us what they're capable of handling.  It is
the failing of the security community to not use that effectively - password-
based authentication is bad because the security community (or at least
security application developers) have made it bad, not because it's inherently
poor.

Here's my proposal for an unmistakable TLS-PSK based authentication mechanism
for a browser:

  When connecting to a TLS-PSK protected site, the URL bar (or something else
  very obvious, say the top border of the page) is set to a colour like blue,
  matching what Mozilla currently does with its yellow for SSL sites.  The
  blue bar then zooms out into a blue-marked dialog box asking for the
  username and password (I'm assuming here that you can't spoof this sort of
  thing in Javascript).  Once the mutual auth of client and server has
  occurred, the blue-marked dialog box zooms back to the blue-marked web page,
  providing a clear connection between all stages of authentication and secure
  display.  All that users have to learn is to never enter their password on a
  non-blue-marked site.

It doesn't solve *all* phishing problems, but it's a darn sight better than
the mess we're in now.

Peter.


---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com



More information about the cryptography mailing list