Current authentication procedures

[Ian Miller]

As has been observed before, existing security procedures are often
seriously lacking in comparison with the supposed requirements for
electronic procedures.  Last night I encountered an example.

A bank, which I have recently opened an account with, phoned me to set me
up on their telephone-banking service.  This was them asking for various
bits of information to allow them to authenticate me, when I used the
service.  Essentially it was a key-exchange operation.  I was asked a few
questions to verify that I really was the account holder.  When it got to
the first question that could not be answered from my phone-book entry, I
asked the bank employee to authenticate herself; after all, she had phoned
me.  They already had far more evidence of my identity than I had of the
callers', and it was already clear that the main purpose of the call was
for them to obtain information from me, not to give me any.  (The _only_
information that caller had provided was knowing that I had recently opened
an account.)  After some discuss it became clear that this was impossible,
as the employee was forbidden to give out any account specific information. 

Assuming it was a genuine bank employee, it is clear that the bank's
procedures make no allowance whatever for authenticating themselves to the
customer, even when they are phoning the customer.  Evidently the
possibility of someone impersonating the bank has not occurred to them.  If
they cannot get the manual procedures right, what chance is there that they
will manage complex cryptographic protocols?

Ian