Re: Statistical Attack Against Virtual Banks

[ssgriggs () JCIUS COM (Swift Griggs)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tue, 8 Feb 2000, Andre L. Dos Santos wrote:
> Many Virtual Banks rely on a fixed length personal identification
> number (PIN) to identify a user. Some banks, allow access to all of
> their online operations after a successful identification, others
> require additional identification, like social security number, maiden
> name or an additional PIN.

You don't mention x509 authentication in your analysis at all. IMHO, your
not doing anything here other than bringing up the age old technique of
brute forcing weak passwords in a circuitous way.

> 3. Defenses One difficulty when performing this attack is to determine
> valid account numbers

There is no excuse for a bank not to use x509 client authentication. Sure
SSL server certificates will help prevent man-in-the-middle attacks, but
banks _must_ be sure they can trust their clients to be who they claim. In
order to do this they must create their own certificate authority or
chained certificate authority. Subsequently they must go through
reasonable lengths to make sure that all requesters of x509 client
certificates are indeed their customers and not someone trying to social
engineer them. To do this it requires time for someone to either verify
them by calling them at the numbers they gave when they opened their
account, and asking them personal questions. They must also identify
themselves with some kind of password, which was set by their customer at
the time when they generated their CSR. This helps to insure mutual trust.
        Furthermore, the bank's server must disallow any attempt at
entering a username and password until they present an x509 client
certificate that was signed by the bank's CA certificate. Once they get
that far, they can only guess at their own account (the server will know
because their client cert will identify them). Additionally a
multiple-bad-guess-lockout should still be in place. There is little
danger of DoS attacks here because if someone has managed to steal your
x509 client certificate _and_ your password to unlock it; odds are they've
got your bank password too. It can be accomplished with a keyboard logger,
and physical access to the victim's machine (or something like Back
Orifice).

Once again crypto helps out a lot. However, possibilities for attack are
still possible when you consider how easy it is to trick people into
executing malicious code, then logging their every move. There is a
difference though, in that you have to pick a target instead of a
distributed "harvest" type attack which you describe.

- --
__________________________________________________
Swift Griggs -  http://voodoomindcontrol.jcius.com
PGP(GPG) Key ID D38E3D91  | InterNIC Handle SG1991
Key fingerprint  for  the key that  I use is here:
010C A7E3 A630 8107 E9A5  F9AD 82D6 BA10 D38E 3D91
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.0 (GNU/Linux)
Comment: Using GPG 1.1

iD8DBQE4oShjgta6ENOOPZERAsIIAJkBIbmsugsM2EKNFNXuvH/A7q3zJwCfZYkJ
Ld8bQBN8KmgMrSkYInpkqME=
=0hlc
-----END PGP SIGNATURE-----