once more, with feeling.

Peter Gutmann pgut001 at cs.auckland.ac.nz
Mon Sep 22 23:24:29 EDT 2008


"Steven M. Bellovin" <smb at cs.columbia.edu> writes:
>pgut001 at cs.auckland.ac.nz (Peter Gutmann) wrote:
>> - Use TLS-PSK, which performs mutual auth of client and server
>> without ever communicating the password.  This vastly complicated
>> phishing since the phisher has to prove advance knowledge of your
>> credentials in order to obtain your credentials (there are a pile of
>> nitpicks that people will come up with for this, I can send you a
>> link to a longer writeup that addresses them if you insist, I just
>> don't want to type in pages of stuff here).
>
>Once upon a time, this would have been possible, I think.  Today, though, the
>problem is the user entering their key in a box that is (a) not remotely
>forgeable by a web site that isn't using the browser's TLS-PSK mechanism; and
>(b) will *always* be recognized by users, even dumb ones.

Yeah, I knew someone would say that which is why I included the note at the
end saying that there was a (much) longer discussion of the issues available.
The problem is that the default has always been to be insecure, and there's no
effective way to get people to move to the secure non-default, or at least
none that isn't relatively easily circumvented by a bit of creative thinking
and/or social engineering.  The problem is really a multi-part one, some parts
of which are easily solveable, others which aren't.

The easy part: New developments.  SSL seems to be pretty much the de facto
substrate for securing network applications (even more so now that we have
DTLS), there's no need to repeat the same mistakes over and over again when
rolling out new SSL-enabled apps - build in TLS-PSK (or TLS-SRP, or whatever),
make it the default, and mark anything else as insecure with big red flags. To
quote Ian Grigg, "there is only one mode and it's secure".  Heck, even getting
away from the current "Connect to remote system, hand over username+password"
would be a massive step forward into the 1980s.

That leaves the harder part, existing apps:

>If this had been done in the beginning, before users -- and web site
>designers, and browser vendors -- were mistrained, it might have worked.
>Now, though?  I'm skeptical.

For existing apps with habituated users, so am I.  So how about the following
strawman: Take an existing browser (say Firefox), brand it as some special-
case secure online banking browser, and use the "new developments" solution
above, i.e. it only talks mutual-auth challenge-response crypto and nothing
else.  At that point you've reduced "Reformat user and reinstall browsing
habits" to "Train users to only use safe-browser when they do their banking,
i.e. 'Never enter banking details using anything other than safe-browser'".
Even if you only get a subset of users doing this, it's still a massive attack
surface reduction because you've raised the bar from any idiot who buys a
phishing kit to having to perform a man-in-the-browser attack.

Peter.

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com



More information about the cryptography mailing list