[114817] in cryptography@c2.net mail archive
Re: Dutch Transport Card Broken
daemon@ATHENA.MIT.EDU (Steven M. Bellovin)
Sat Feb 9 18:40:11 2008
Date: Thu, 7 Feb 2008 05:42:00 +0000
From: "Steven M. Bellovin" <smb@cs.columbia.edu>
To: pgut001@cs.auckland.ac.nz (Peter Gutmann)
Cc: jamesd@echeque.com, pgut001@cs.auckland.ac.nz,
cryptography@metzdowd.com, perry@piermont.com
In-Reply-To: <E1JMyVS-0003xG-4z@wintermute01.cs.auckland.ac.nz>
On Thu, 07 Feb 2008 17:37:02 +1300
pgut001@cs.auckland.ac.nz (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 majordomo@metzdowd.com
