In article <[EMAIL PROTECTED]>, Joerg Schneider <[EMAIL PROTECTED]> writes
>Florian Weimer wrote: >> I think you can forward the PassCode to AOL once the victim has >> entered it on a phishing site. Tokens à la SecurID can only help if > >Indeed. > >> the phishing schemes *require* delayed exploitation of obtained >> credentials, and I don't think we should make this assumption. Online >> MITM attacks are not prevented. > >So, PassCode and similar forms of authentication help against the >current crop of phishing attacks, but that is likely to change if >PassCode gets used more widely and/or protects something of interest to >phishers. as in the story of the two hunters and the bear ... the banks only need to outrun another vulnerable target: http://www.netfunny.com/rhf/jokes/89q3/oldbear.555.html so making passive password/PIN collection ineffective and requiring phishers to operate in real-time may be a sufficient win. >Actually I have been waiting for phishing with MITM to appear for some >time (I haven't any yet - if somebody has, I'd be interested to hear >about), I've been shown something similar last July ... which was, IIRC, a PayPal phish where the web page you went to checked that the password it was given was in fact valid. It wasn't a full-scale MITM attack, but it did have some real-time elements. I haven't been bothering to look at phishing sites recently, so I don't know if the technology to do this has become the general state of the art, or if it was just one gangs unique coding style ? >because it has some advantages for the attacker: > >* he doesn't have to bother to (partially) copy the target web site > >* easy to implement - plug an off-the-shelf mod_perl module for reverse >proxy into your apache and add 10 minutes for configuration. You'll find >the passwords in the log file. Add some simple filters to attack PassCode. > >* more stealthy, because users see exactly, what they are used to, e.g. >for online banking they see account balance etc. To attack money >transfers protected by PassCode, the attacker could substitute account >and amount and manipulate the server response to show what was entered >by user. this is the fundamental problem with using the passcode, the user is "signing" just the single bit "I authorise" rather than the full bag of bits {amount, payee, timestamp} ... as soon as you write out formally what is going on the shortcoming is entirely obvious >Assuming that MITM phishing will begin to show up and agreeing that >PassCode over SSL is not the solution - what can be done to counter >those attacks? > >Mutual authentication + establishment of a secure channel should do the >trick. SSL with client authentication comes to my mind... The problem with that is that people want (or at least think they want) to use their online banking from home, from work and from a cybercafe whilst they are on holiday or a business trip. Carting around the credentials (and a secure way of checking them) is a non-starter However, the banks could do a lot by starting to distinguish between run-of-the-mill transactions : "pay my gas bill" and more sensitive ones such as "set up a new payee" (or indeed "change my gas company to Nigerian Oil&Gas"). Insisting that the sensitive ones were only done from the secured (and credential rich) home site would help. They could also check the IP address of the connection and form a view as to its likely validity! Yo rule out a MITM one might employ a secure side-channel (SMS text message to one's mobile phone perhaps -- certainly a very plausible approach in SMS-aware Europe) ... some banks are already using this; but only as a cheap replacement for a SecureID :( ... so it's ineffective. Now if Bill's browser could display the last six digits of the SSL key then those could be compared with the SMS message and the customer would know that they were safe.... the banks might even go for this solution because it dumps the decision to go ahead (and hence the risk as well) onto the customer :) -- richard Richard Clayton They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. Benjamin Franklin --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]