|
Protection against... |
Detection... |
Ease to install |
User usage
(green=easy) |
| |
funds transfert |
simple phishing |
MITM phishing |
ISP pharming |
trojan keylogger |
advanced trojan |
before-fraud |
after-fraud |
| |
|
|
|
|
|
|
N/A |
N/A |
|
|
Goal : ensure bank deals with the real customer and reciprocally
Installed by : business lines
Here is the only solution where you won't find an associated home made tool. Indeed, a working two factor authentication solution will require a huge improvement of your system (unless you consider phone as a proof of authentication. In this case, have a look at SMSA tool).
Required by the FFIEC, the two-factor authentication — e.g.
'something you know', 'something you have' or 'something you are'
— is increasingly used and deployed. It is often used as the
'something you know' / 'something you have' couple to authenticate
users. However, it is required that the proof of factor does not travel
over the same channel, as if it does, attacks are still possible.
What is really important, is to perform mutual authentication. A user
has to be confident about the identity of the bank in order to prevent
him from giving away his credentials to a malicious Web site. In turn,
the bank has also to be confident about the identity of its customer,
to prevent from making a money transfer on a malicious account.
This mutual authentication can be established when two differents
channels are used to exchange information between a bank and its
customer.
We already presented a SMS authentication which is a kind of TFA using
two differents channels. Other solutions can also be used to complete
this TFA requirement.
Wikid
is offrering an interesting solution using a software client token that
uses public key cryptography to ensure the client authentication. This
authentication can be made on a domain basis rule so that it's possible
to login on several area with a single token. What is interesting here,
is that this token has been made available on several platform.
Nevertheless, it might be possible for an advanced trojan to steal the
token private key.
A PKI that would be fully dedicated to user authentication, may also be
interesting. Despite the high cost of this solution, this is a very
interesting way to achieve mutual authentication. The certificate
distribution might also be difficult to manage when dealing with
customers. Furthermore, some advanced trojans or rootkit might also
might also be able to be steal the private key, or at least hook the
browser SSL library, therefore making the solution useless.
If you're interested in managing your own PKI, have a look at openca. Commercial companies will also be glad to offer their services on this part.
To prevent cryptographic key theft on the local machine, it is possible
— and it may even be the best way — to delegate this
cryptographic function to an external terminal using a smartcard, and
only have API/driver for reading on the local computer. EMV (Europay
Mastercard Visa) defined the interaction at both the physical and the
application levels to allow financial operations. The main issues here
are related to the potential loss of a token, or a customer that may
forget his token somewhere.
