Protecting yourself from your customers

The recent ‘hack’ of the BA Executive Club reminded me that, whilst one can do a pretty thorough job at protecting your systems from compromise, you’re going to struggle to protect yourself from customer stupidity.

Users seem to take little responsibility for their own security. What’s the worst that could happen?

“My bank account/credit card was raided, but they gave me my money back.”

“My account on web site X got raided, but they credited it”

Security isn’t really their problem, or at least that’s a common response I hear when teaching end users about security. It’s the web site owners/the bank/the government/someone else’s problem.

So in the face of this, what are you supposed to do?

Every time I see a big data breach, I’m less interested in the card & personal data leaked – whilst it’s nasty stuff, I really want to know about the consequential damage that will come from theft of password hashes. What other, more secure, web sites will have customer accounts compromised through password re-use?

Here’s an examples of stolen SHA1 hashes:

There are numerous cases of stolen hashes, pinched from less secure sites, being cracked and then re-used against other sites. Some accounts on the Tesco Clubcard site were probably compromised in this way in early 2014, and discussion around the BA Exec Club accounts compromise suggests that they were done in a similar manner.

Who hasn’t had a weird email from a friend’s Yahoo or Gmail account, usually a poor attempt at phishing. How was the account compromised? Most likely a re-used password, stolen in a breach of another site.

Another high profile breach? Check the breach data against your own customer accounts

Facebook took an interesting approach on the back of the Adobe and other breaches – they made attempts to check for Facebook user account email addresses that were present in the breach data. Where there was a match, they reset the customer account password.

You could do something similar, sites such as http://haveibeenpwned.com run by the awesome Troy Hunt attempt to collate breach data that has been dumped publicly. There’s an API you can use to make the process much easier.

I know, you’re going to get some pushback from your ecom/online teams, but what is better? Ending up in the press through a bunch of customer accounts compromised, or annoying a few customers with a password reset, when they should really know better…

You could go one step further, to avoid resetting passwords unnecessarily – if the hashes have already been cracked & published, how about running the plaintext through your web site’s own hashing/salting process and verifying if the password has indeed been re-used.

Helping your customers out

Promote password manager apps – they’re usually free for personal use; they create strong unique passwords for each site the user goes to, without the overhead of remembering them.

Yes, I accept there is an ‘all eggs in one basket’ issue, but I think that using a password manager is far better than the status quo, where Joe Public uses the same simple password for most web sites they have accounts on.

Use 2FA/2SA – this might seem like overkill for a retail site, but remember the downside – a breach with your brand name splattered all over the media. You need to capture the customers mobile number anyway for delivery information etc, so why not SMS them a one time code? They’ll probably thank you for making auth easier on their subsequent visits to your web site!

Consider federated auth or social login – Facebook and others make it easy to integrate their login process. It’s an attractive method to make auth to your site easy for customers. There is of course a downside, in that you’re reliant on others. Facebook had an outage for about 30 minutes a while back, which could cause quite a blip on your usage.

And if the 3rd party providing social login gets breached, you’ve got real problems. But just bear in mind where users are at today with their security…

Never forget, your customers think security has little to do with them. That’s your problem, even when they re-use passwords everywhere.