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

[Alaric Dailey]

Peter Gutmann wrote:

>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.
>
Show me one sight that uses PSKs to secure its connection to the masses. 

>  By extension, ATMs are also infeasible.
>  
>
ATMs would be infeasible if they were not a 2 factor authentication
system, and every day we see more cracks in the way that system is
implemented.  Starting with the way the PSKs are shared. 

http://news.bbc.co.uk/1/hi/technology/4183330.stm


>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.
>
>
>  
>
Your "solution" doesn't cover any of the problems with phishing, come
on, if all we have is a preshared key, how is a user who can't even
verify the details of a cert going to know if the site they have
connected to is legitimate, all those wonderful AOL users will be easily
duped into putting in their 1 weak password of "love", "sex", "god" or
"money" and the phisher will have their info.   And we won't even get
into the fact that easy to guess PSKs are the one real weakness 
symmetric encryption systems that actually can keep the secret of their
PSK. I also wont start on a rant about how all those wonderful AOL users
won't be able to keep track of all those PSKs if  they are unique to the
user.

With PSK you cannot verify

-not domain ownership
-the key belongs to the domain you are connecting to
-the key hasn't been shared with an evil party that is now impersonating
your favorite website

in fact without the details in the cert there is nothing to verify. 
Without Public/Private key encryption there is no mitigation of a man in
the middle attack, verification of either party, for sites like Amazon
or Hotmail, PSK introduces many many more problems than it will ever
solve. 

The only exception might be is if the 2 parties have a unique PSK such
as an banks ATM system, and there are systems that handle just that kind
of massive symmetric key storage (RSA makes a nice one) but is that
safer than Public/Private key encryption? No, if it were, PGP/GPG and
X.509 wouldn't exist.

The Achilles heel of symmetric encryption is always the same, sharing
that key securely, and a secret that is shared is not a secret. 




-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3544 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20050907/23b345a6/attachment.bin>