Un-hackable customer data: how Equifax can prevent future hacks

By Frank Forte

Image courtesy of Pexels

Keep your customer’s data secure. It’s your responsibility. You ask for that data, you specifically require it from your customers to process credit checks. So, keep their data safe.

Equifax could have done many, many things to protect customer data. This post is about one of those things, storing data in an un-hackable way.

Anyone who writes code will at some point learn about hashes. There are ways to use hashes of customer data instead of the customer data itself to meet business requirements.

A hash is a scrambled string of characters, for example,3c1fd1b2c915eacf, that is created by taking a piece of data such as a social security number, SIN or date of birth, and using a cryptographic algorithm to scramble that data in a repeatable way.

The great part about hashes is that they are searchable. You can store a hashed version of someone’s name, SIN number, or other sensitive or personally identifiable information (PII), and you can find that user’s record by typing in the original data when required, which can be hashed with a program, then the database can be searched for a matching hash. Even better? They are un-hackable. Even if a hacker steals this data, it is meaningless and has no value, what are they going to do with “3c1fd1b2c915eacf”?

What about data that you need to send to third parties? You need the original data in some cases. You can link the hashed records with an encrypted record that only contains the bare minimum information needed to conduct business. The hash search can pull up that encrypted data, then the data can be decrypted and sent back to authorized employees or third parties over an encrypted connection, like https.

Now that you have an idea of what is possible, how should we apply this knowledge?

Organizations need a policy for classifying data.

More specifically, determine how each field is used and how each should be stored:

A) required for search (hash)

B) required for validating correct information supplied (hash)

C) required by an outside party (encrypt)

D) required for Analytics or statistics? Ideally do not include PII and do not link it to the original records, so that data still provides insight, but it is anonymous, so hackers still find very little value in stealing the data, and liability is very limited.

E) how long is each field required? Delete data once it’s useful life is over. You would be surprised how much data can be deleted almost immediately with minimal impact on operations. This minimizes the amount of information exposed if and when a hack does happen.

Once customers give you their data, they don’t have control of that data anymore, so they rely on you to keep it safe! Be smart, invest in better data storage and retention policies.

If you need a consultant on preventing hacks in your organization, contact me. If you you are a software developer just stopping by to learn more, please make sure you research why you need to add a “salt” to your hashes, and use up to date hashing algorithms like sha256.

Thanks for your interest!

Copyright 2017. Frank Forte. Unauthorized reproduction of this work is prohibited.

This entry was posted on Friday, September 22nd, 2017 at 7:31 pm and is filed under Business, Cyber Security. You can follow any responses to this entry through the RSS 2.0 feed. Responses are currently closed, but you can trackback from your own site.