At 3:52 AM +1200 9/11/05, Peter Gutmann wrote:
Sure, but those issues have already been addressed by pretty much every site that needs to use passwords or user authentication for any reason. That's the point I was trying to make, that the standard response to use of passwords (or PSKs) is they don't work, they don't scale, you can't handle revocation, distribution is a problem, etc etc etc. However, despite all of these issues, all the sites that need to authenticate users are using passwords, and they seem to be doing OK with that.
In many deployments of "SSL first, then authenticate the user with a password", the "site" consists of two or more machines. Many or most high-traffic secure sites use SSL front-end systems to terminate the SSL connection, then pass the raw HTTP back to one or more web servers inside the network.
The reason I bring this up is that the SSL server generally does not have access to the users' credentials. It could, of course, but in today's environments, it doesn't. Changing to TLS-PSK involves not only changing all the client SSL software and server SSL software, but also the what the SSL server's role in the transaction is.
I think it depends on how much pain banks and merchants are willing to endure due to phishing attacks.
Exactly. So far, the banks have not found it that painful. If they had, they would be spending much more money on reducing the problem. Banks are extremely good at measuring risks and costs, and then counterbalancing them. Banks do not feel like the costs are that high yet. They haven't even started any significant anti-phishing efforts. Said another way, the anti-phishing efforts so far have been cheap and mostly ineffective.
Yeah, that's still a possibility, although I think you can probably train most users to not do this.
Even though pretty much all of our user security training efforts have been a dismal failure so far, you assume that we'll get this one right? If we don't, then the large cost of upgrading everyone's SSL, and the banks' SSL processes, is wasted. That's a interesting risk.
--Paul Hoffman, Director --VPN Consortium --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
