AOL Help : About AOL® PassCode

[Richard Clayton]

In article <41DD1672.2070207 at joergschneider.com>, Joerg Schneider
<js at joergschneider.com> 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 majordomo at metzdowd.com