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]
