Ian G wrote, On 2008-10-14 14:27: > People in the apps security field hold out high hopes for TLS-PSK as > a great aid for phishing; it would be a shame of that didn't happen
PSK is just a new name for a very old idea: shared secrets. When it comes to phishing, shared secrets aren't the solution, they're the problem. Phishing teaches us that: - users WILL NOT even try to be sure that they're really communicating with their intended site before authenticating to it. Even if the URL is https://L33t.haX0rs.ru/, a web page that looks even remotely like Bank of America's login page will entice BofA users to try to login. - If a user is ABLE to give away his authentication credentials, he will do so, even if he must overcome great obstacles to do so (bug 460374). If it's in his head, and he can type it or speak it, he will give it away to almost anyone who asks for it, if they pretend to be the intended server, or even if they merely offer him a chocolate bar. http://news.bbc.co.uk/1/hi/technology/3639679.stm Shared secrets are old technology. They were the only technology used in WW2. It is possible to use them securely. Military organizations did so in WW2, through the use of rigorous training and human protocols that involved changing keys frequently (paper pads of one-time keys). But using a password as a shared secret *IS* the big problem. Passwords have low entropy, and fall to dictionary attacks. Most schemes that use them are vulnerable to replay attacks (which is why phishers want them). Passwords typically get reused way too many times. Even if the password itself is not transmitted over the wire, human users are easily tricked into revealing them. All these problems are well known and old. They are the reason that so much effort has been spent on research and development of public key cryptography and so-called zero knowledge proof authentication mechanisms. These things were developed because they allowed authentication that did NOT require the party who would verify authenticity to possess the very thing with which it could generate a forgery, a shared secret. They were developed because the enterprises (and governments) who needed encryption desperately wanted solutions to the problems of shared secrets. The solution to these problems requires an authentication scheme in which users simply CANNOT give away the information needed to forge their authentication credentials. We've had such systems for over 20 years now. The patents have expired. But people still cling to shared secret passwords. SSL (now TLS) was the first commercially successful protocol to incorporate all the parts of the solution: - strong encryption - strong message integrity checking - strong session authentication - replay attack resistance - short-lived encryption keys, not reused Today, saying that you use SSL or TLS means something precisely because it is such a strong protocol, being resistant to so many kinds of attacks, and not depending on shared secrets from long term authentication. The terms SSL and TLS have become synonymous with good secure network communications. Consequently, many people desire to be able to say that they use SSL/TLS even when they are using a scheme that does not possess the strong security properties of SSL/TLS. TLS-PSK is a thinly veiled (or simply unveiled) attempt to lay claim to those precious marketing terms "SSL" and "TLS", even when using that bad weak old shared-secret technology for authentication. I believe the reason its proponents call it "pre shared keys" rather than "shared secrets" is because of the wealth of literature about the problems of shared secrets. Using a new TLA avoids that association. When it comes to authentication by shared secrets, there's no real security advantage to using them in the SSL/TLS protocol itself, as opposed to using them in the application protocol after the TLS session is established. Strong binding of the authentication information to the TLS "master secret" session key (thereby avoiding MITM) can be accomplished in authentication that is done after the TLS session is established. See http://www.ietf.org/internet-drafts/draft-ietf-tls-extractor-02.txt and http://www.ietf.org/internet-drafts/draft-josefsson-sasl-tls-cb-01.txt . Doing so inside TLS simply allows the scheme to be called TLS, which makes it much more marketable. Nothing in the design of TLS-PSK requires that the shared secrets be passwords. It would be possible to use some strong computer generated keys that are not derivable from passwords, and which are never shown to the human users, so that the human users simply cannot reveal them. The scheme proposed in the SASL paper cited above is such a scheme. But without exception, all the proposed uses of TLS-PSK that I have seen intend to have the shared secrets be entered by a user when needed, as a password is entered. Any value entered by the user, from which the secret key is derived, is a value that the user can be tricked into revealing. The very first request we ever received to implement TLS-PSK was from the CTO of a firm that was going to make little gizmos that displayed a frequently changing hexadecimal key value. The device would generate these values in synchrony with a similar device at the server end, so the user would not be using a password and the value would be changing. Sounds good, right? But the request was to allow browser users to be able to type in the PSK key seen on the gizmo directly into a browser window. That means: a) The user can be tricked into typing the value into a web page, from which an attacker obtains the value and immediately reuses it to authenticate as the user, and b) Nothing prevents a password from being entered into that PSK dialog instead of a value from a gizmo. If one server can use it with values from gizmos, other servers can just use it for passwords. Perhaps if the gizmo had been a USB fob, so that the browser could read the key value directly out of it, without it ever been seen by human eyes, it might have been more attractive. Of course, FF3 already has a strong user authentication scheme that avoids all these problems of shared secrets, built-in. It involves keys that are never seen by the user, never sent over the wire, not breakable with an offline attack in our lifetimes. Authentication performed that way is not vulnerable to replay, and does little or no harm if performed with the "wrong" server (except perhaps for user tracking). It's already part of the TLS standard, and in NSS. Need I name it? Bottom line: if browsers change to allow https to be done without any server authentication, merely using passwords as shared secrets, lots of people with rush to use that, mistakenly believing themselves to have obtained security thereby, and successful phishing attacks will INCREASE. We've come too far in the direction of providing real security to give back all the ground we've gained. Now, as MITM attacks are rising, is not the time to go back to weak and vulnerable shared secret "security". _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
