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.

Delivering Demands for Blind Acquiescence

The DeliveryDemon is becoming increasingly fed up with growing expectations of blind acquiescence. It may make it easier for an organisation to use ill-trained operatives and unintelligent processes if customers mindlessly comply with demands for vast amounts of sensitive personal information despite the absence of justification for the request. After all, if everyone provides every piece of information which might be required for every conceivable circumstance, the admin drone can just tick a load of boxes and the organisation doesn’t have to bother making the effort of deciding which information is actually required. And the DeliveryDemon is fully aware that many such demands for information are purely box ticking exercises, with no intelligent use being made of the information gathered. She is also fully aware that, when no thought is applied to deciding which information is needed, it is highly likely that an equal lack of intelligence and diligence is applied to the storage and management of information collected.

This rant was provoked by the need to go through a ‘proof of ID’ process, where the conversation with the call centre went something like this:

DD – You don’t need my marriage certificate since I never changed my name – why do you need my divorce documentation?

CC – It’s the regulations

DD – Which regulations?

CC – HMRC regulations

DD – Which HMRC regulations?

CC – I’ll check with my supervisor

CC calls back – It’s our own rules

DD – Why do you need it?

CC – It’s our rules

DD – If you need it you have a duty to explain why it’s needed

CC – I’ll get someone to call you back

CC2 calls back – We might be able to accept copies with a letter

DD – That wasn’t my question. You have already said you don’t need my marriage documentation since I have never changed my name. Why do you need my divorce documentation?

CC2 – We don’t need it.

Unfortunately, this sort of conversation is, in the DeliveryDemon’s experience, all too common. Far too many organisations feel entitled to pressurising customers into providing information well in excess of the organisation’s real need. Let’s look at what actually happened here.

• First there was a request for information without an adequate explanation of why it was required.
• Second there was the assumption that a reference to some unspecified regulations would make a customer stop asking questions.
• Third there was an assumption that a reference to HMRC would stop a persistent customer from asking questions.
• Fourth, there was an admission that it wasn’t valid to blame the law or the taxman, that this was an internal blocker.
• Fifth there was an attempt to avoid the issue by offering an alternative (certificate copies), in the hope that the customer would be fed up enough to comply.
• Sixth was the admission that the information was not required.

This was not an isolated incident. The DeliveryDemon frequently encounters organisations which behave as though Data Protection legislation didn’t apply to them. If there is a genuine need for a piece of information in one specific instance, they embed the requirement in their general process. They try to blame the law, or various bureaucratic bodies. Call centre operatives are trained to give woolly and misleading responses to questions about the need for information. They expect the customer to be acquiescent and unquestioning, in the interests of lazy process.

It is simply not good enough. The DeliveryDemon is familiar with data protection provisions, and has a good understanding of how a wide range of businesses operate. This puts her in a good position to challenge demands for excessive information. Not everyone is so lucky.

It’s not a matter of being awkward. Our personal data has value, and the cost to the individual of identity theft is massive. Both the law and business ethics demand that organisations only collect the data they need, and on the basis of explicit customer agreement and understanding. It is shocking how many organisations are prepared to ignore both the law and ethical considerations. Unfortunately, the UK’s enforcement of data protection legislation is weakly and tardily applied – enforced would be too strong a word. It’s down to the customer to resist the tsunami of demands. The DeliveryDemon recommends the following questions:

• Why do you need it?
• Which legislation requires it?
• No, I need to know exactly which legislation so I can check the requirement.
• Who will have access to it?
• How will it be kept secure?
• How long will it be held?

You don’t have to be paranoid……

The DeliveryDemon was looking at security settings on the laptop recently after the moderate paranoia setting started blocking WordPress cookies. To check what was happening she used the ‘prompt’ setting, requiring manual approval of cookies. Cue a very tired hand, and the site concerned was a perfectly respectable one! A big disconnect appears to have grown between website development practice and security practice. It appears that we are offered two choice

•  blind reliance on automated cookie approval / rejection
• total unusability.

This little experiment has the DeliveryDemon asking a LOT of questions:

• What are these cookies doing?
• How much of my storage / processing power are they hogging?
• What’s going on when a ‘respectable’ website (not WordPress) wants to install 20 or more cookies per screen?
• Why don’t website designers realise that a cookie plague makes the most honourable of organisations look dubious?
• Whatever happened to respecting the right of the user to choose an appropriate security setting?

The DeliveryDemon appreciates that there’s a balance to be struck when it comes to website stats and marketing requirements. But if the designers come up with something better than forcing the user to change security settings for all sites to fit the requirements of one particular site, there’s something wrong.

If the medium paranoia setting stops a website from working, then someone has delivered a very poor level of security.