On Thu, 07 Feb 2008 17:37:02 +1300 [EMAIL PROTECTED] (Peter Gutmann) wrote:
> The real issues occur in two locations: > > 1. In the browser UI. > 2. In the server processing, which no longer gets the password via an > HTTP POST but as a side-effect of the TLS connect. > > (1) is a one-off cost for the browser developers, (2) is a bit more > complex to estimate because it's on a per-site basis, but in general > since the raw data (username+pw) is already present it's mostly a > case of redoing the data flow a bit, and not necessarily rebuilding > the whole system from scratch. To give one example, a healthcare > provider, they currently trigger an SQL query from an HTTP POST that > looks up the password with the username as key, and the change would > be to do the same thing at the TLS stage rather than the post-TLS > HTTP stage. There's another issue: initial account setup. People will still need to rely on certificate-checking for that. It's a real problem at some hotspots, where Evil Twin attacks are easy and lots of casual users are signing up for the first time. --Steve Bellovin, http://www.cs.columbia.edu/~smb --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]