[plug] Banks Online

[Christian]

On Thu, Jun 29, 2000 at 12:13:52AM +0800, Mike Holland wrote:
> On 27 Jun 2000, Christian wrote:
> 
> > than trying to brute force even 40 bit SSL.  For example, the user is
> > probably authenticated by their account number (relatively easily
> > retrieved) and a small password/PIN.  In such a system the entropy
> > involved in the shared secret being exchanged is very likely less than
> > 20 bits.  Since the SSL doesn't authenticate the user (only the bank)
> > this is the weak point in such a system.  In such a protocol only a fool
> > would try to brute force the SSL.
> 
> Interesting. How is this?  Known plaintext wont let you crack 128-bit SSL,
> will it? And you cant do a brute force attack on the PIN, because the bank
> will lock the account after n errors. How does a 3rd party get the PIN
> without breaking the SSL, or is there another way to fool the bank?

How big is n?  It's not like an ATM machine that will take your card if
a person (presumably an imposter) incorrectly inputs the PIN.  If an
attacker makes n wrong guesses then someone's bank account is shut down
(at least from access via the Internet).  If anyone's bank account can
be shut down by a malicious user making n guesses (easily automated)
then there would seem to be a problem with the whole idea of Internet
banking.  Unlike the ATM-swallows-card scenario which deprives the
attacker of the ability to continue attacking the system and assists in
the return of the authentication token (key card) to the legitimate
owner, disabling a person's bank account inconveniences them (possibly
severely) and merely delays the attacker.  Consider running many of these
attacks in parallel: how long would it take to find a valid PIN?
Assuming account IDs are generated in a non-random manner (seems
likely).  An attacker generates 2000 account IDs and writes a small
script to automate a brute force attack.  How many accounts does the
attacker have to try?  My point is that people may be all flustered over
40-bit rather than 128-bit key lengths used in SSL while not really
considering that the weakest link in the system most probably isn't the
cryptography at all.  In practice it very rarely is.

Security systems and infrastructure need to mature a lot before I trust
them enough to do my banking over the Internet.  Currently best-case
scenario is that my account can be disabled by anyone who guesses/knows
my account ID (*wonders if this is the same as the BSB number that is
given to every employer I have or have had*).  Worst-case scenario is
that someone guesses my 4 digit PIN (~10 bits of entropy: 40-bit keys
are suddenly looking a lot better!) and has complete access to my bank
account.  It's taken security systems used by banking and financial
institutions a long time to mature (see Ross Anderson's paper, "Why
cryptosystems fail" for details of some of the lessons learnt) and
Internet security systems are currently nowhere near that level of
maturity.  I wouldn't necessarily advise someone not to use Internet
banking but I think they should be aware of the potential risks.
Anyway, back to my original point which is that most of the time it's
not the cryptography you have to worry about -- most systems are badly
insecure to begin with.

Regards,

Christian.