Delivering Complexity at the Expense of Security

The DeliveryDemon is frequently flabbergasted by the sheer stupidity demonstrated by so many financial institutions when it comes to security. They obstinately pretend that imposing complexity on account access equates to security, in the face of all evidence to the contrary. At the same time they refuse to acknowledge that their own processes are often staggeringly insecure.

Some time ago after a trip abroad, the DeliveryDemon had a phone message claiming her credit card had been compromised, and asking her to ring the issuer on an unidentifiable number. It clearly sounded like a scam which needed to be reported to the issuer. So the DeliveryDemon phoned the switchboard and asked to be put through to the person who had left the message. She was unsurprised when the switchboard had never heard of this person, and asked to be put through to the security and fraud department – where she found herself talking to the person who had left the suspect message.

So how many security mistakes was that?

  • Leaving a message about a card compromise on a landline answering machine without knowing who might pick it up
  • Asking the cardholder to ring a number which could belong to any scammer
  • Creating a situation designed to justify a request for secure information, using a process riddled with fundamental security flaws
  • Preventing a customer from carrying out basic security checks by using a name not recognised by the switchboard.

But the biggest mistake of all was the fact that some time afterwards the DeliveryDemon had to deal with the identical flawed process. Needless to say, the DeliveryDemon had complained to the card issuer on the first occasion, yet the organisatioj had taken no notice of the complaint and had continued knowingly to operate processes which were fundamentally insecure.

This type of stupidity is remarkably common in the financial services sector, and a couple of very similar examples are described in an earlier post .

https://deliverydemon.wordpress.com/2012/04/02/delivering-poor-banking-security/

The other side of this refusal to operate secure processes is a determined effort to create barriers to prevent a customer from accessing their own funds. This goes hand in hand with lengthy and inequitable Ts and Cs which attempt to absolve banks from any responsibility whatsoever. The DeliveryDemon recently encountered this while opening a very basic bank account. This ‘simple’ account required no less than EIGHT authentication factors, including providing answers to some remarkably stupid questions.

  • A memorable number? Seriously? Numbers are not intrinsically memorable. Those which are memorable usually relate to public domain information, which is hardly secure.
  • Details of various third parties? Public domain again. It is also questionable in data protection terms whether a bank should be asking for information about third parties who have nothing to do with the account.
  • Favourite TV programs, newspapers, historical person, sleb, town? Get a life! This sort of preference is transient and likely to be forgotten months or years down the line when it is eventually needed in order to deal with some call centre drone who is not empowered to think beyond the mindless detail on the screen in front of them.

This sort of pseudo security is not just stupid in its own right, it is creating a situation where complexity makes life difficult for the customer, while being used as an excuse for financial institutions to try to avoid their own responsibilities.

Put these so-called security processes in the context of today’s digital native. Basic security advice is not to use the same details in multiple places, since compromise of one account can lead to compromise elsewhere. Typically, an account asks for 4 pieces of information, even when no financial transactions are involved. Try counting them up. Even without an intricate lifestyle the following range of accounts is pretty commonplace.

  • Mortgage
  • Mortgage-related insurance
  • Life insurance
  • Health insurance
  • Current account
  • Savings account
  • Debit card
  • Credit card
  • ISA
  • Pension
  • E-mail account
  • Work e-mail account
  • Mobile account
  • Landline / broadband account
  • Car insurance
  • Car radio code
  • Electricity account
  • Gas account
  • Water account
  • Council tax account
  • Supermarket account
  • Amazon account
  • i-Tunes account
  • Comparison site accounts – up to half a dozen
  • Social media accounts – another half a dozen
  • Technology support arrangements – say 3
  • Travel accounts for commuters – another couple
  • Online information sources such as newspapers, news sites and the like – say 3.

All of these want a login ID and a password, plus several additional pieces of information for ‘security’ should you be unable to log in. Security guidance suggest that unique information should be used for each situation, and that the information should not be written down in a recognisable format, even when months or years may elapse between accesses to the account.

Put this into the context of the real world. Current security guidance expects the individual to memorise in excess of 172 unique pieces of information, and to relate each piece of information to one of 43 or more situations. Current practice is for Ts and Cs to forbid keeping written records of passwords in any useful format. This is complete nonsense, not security.

So what’s the answer? There are organisations which can be used to store multiple passwords, but these then become a single point of failure should the access password be compromised or the organisation’s own security be breached. It’s not clear whether this sort of password storage is acceptable under access Ts and Cs either.  Even if banks start to give some form of approval to these organisations, it could be withdrawn, leaving the customer with the option of dealing with multiple password holders or changing to a new one. If a security breach underlies the reason for change, that would mean working through every single account to change access details. In some circumstances that may mean the delay of going through the account provider to replace codes which they do not allow the customer to change.

The current security situation is clearly unsatisfactory, ineffective,  and unfair to the customer. The DeliveryDemon thinks it is time that organisations which are responsible for security got together with both security and usability experts to come up with a solution which is designed to protect the customer’s interests, not a solution based on allowing financial institutions to avoid responsibility.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: