-----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-----
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 15:33:58 PDT