"Steven M. Bellovin" <[EMAIL PROTECTED]> writes: >On Fri, 01 Feb 2008 13:29:52 +1300 >[EMAIL PROTECTED] (Peter Gutmann) wrote: >> Actually it doesn't even require X.509 certs. TLS-SRP and TLS-PSK >> provide mutual authentication of client and server without any use of >> X.509. The only problem has been getting vendors to support it, >> several smaller implementations support it, it's in the (still >> unreleased) OpenSSL 0.99, and the browser vendors don't seem to be >> interested at all, which is a pity because the mutual auth (the >> server has to prove possession of the shared secret before the client >> can connect) would significantly raise the bar for phishing attacks. >> >> (Anyone have any clout with Firefox or MS? Without significant >> browser support it's hard to get any traction, but the browser >> vendors are too busy chasing phantoms like EV certs). > >The big issue is prompting the user for a password in a way that no one will >confuse with a web site doing so.
HCI people have been studying this for quite some time, and there's been a lot of good work done in this area. Because of the amount of information, I'll answer indirectly via a link (warning, it's a partial book draft and is currently ~140 pages long): http://www.cs.auckland.ac.nz/~pgut001/pubs/usability.pdf Even without this detailed analysis, one of the Mac browsers (Safari?) already has a quite distinctive password prompt that rolls down out of the menu bar at the top. Sure, you can spoof that if you own the browser, but if malware owns your browser then you're toast anyway. >It might have been the right thing, once upon a time, but the horse may be >too far out of the barn by now to make it worthwhile closing the barn door. That's the response I got from a browser developer when I talked about this about a year ago, "Sufficiently sophisticated malware can spoof any piece of browser UI, so let's just give up and admit that the phishers have won". At the moment, after 15-odd years of work, the state of the art for both major secure-channel protocols is to connect to anything listening on port 22 or 443 and then hand over the user's password in plaintext form (although inside a secure tunnel, as if that made any difference) [0]. This is only just barely better than the 1970s-era telnet in that the authenticator is still handed over in plaintext, but at least you can't capture it with a packet sniffer. Moving to a challenge-response mechanism (which PSK and SRP aren't really, it's more a bit-commitment since there's no real challenge or response process [1]) would at least move the security into the late 1980s. As a side-note, I was talking to a security person from a large (multi- national) bank recently and they mentioned that they were slowing down on the push to move to two-factor auth (real two-factor auth with SecurIDs and the like, not the gimmicks that US banks are using :-) because the problem isn't authenticating the user, it's authenticating the server and/or the transaction, and most two-factor auth tokens can't do that. As a result they're not going to commit to sinking much more money into something that doesn't actually solve the problem. So mutual client/server auth is something that's of concern to more than just some geeks on security mailing lists, it's coming onto the radar of large financial institutions as well. Peter. [0] By "443" I mean HTTP over SSL/TLS, obviously. [1] Actually this is neither challenge-response nor bit-commitment so in the absence of anything better I'll propose "failsafe authentication" because the other side doesn't get your authenticator unless they can prove they already possess it. In other words if the authentication process fails, it fails safe. --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]