It seems not a day goes by without some major data breach occurring on businesses systems. Anywhere from a few thousand records to many millions at a time, containing information ranging from names, addresses, telephones number, dates of birth and account details, etc.

One thing I have noticed, that seems to be a constant throughout all of these data breaches, is that they normally include the person’s email address. Now you may think this is an innocent piece of information that on its own has little value to the hacker; but you could not be further from the truth – the email address is a keystone to the value of the rest of the information. Let me explain why.

With an email address, you have the following:

1. A way to contact the person associated with the information, great for phishing attacks that can be specifically targeted based on the information discovered from the data breach.
2. A way to search for and match other information from other data breaches and thereby increase the depth of knowledge on the individual. There is plenty of evidence out there that this is exactly what hackers are doing.
3. A means to try to sign into accounts and services that use said email address as an account identifier. Say part of the data breach is a weakly hashed password, that hash could be reversed and then used to try to get into other online services; i.e. if the email is auser@onlineemail.com then it’s worth trying to use the password with the onlineemail.com service to try to get into the email service itself.
4. A means, when selling on via the black market, exactly whom and what organisation the data relates to. Consider it a form of black market ‘providence’.

This is the ‘beauty’ of email addresses to hackers, they create a naturally unique identifier they can use to bring together a web of otherwise difficult to correlate information – the majority of the time to a specific individual.

Now I know Apple is providing ‘one-shot’ email addresses to reduce this risk, and other providers offer disposable email addresses; but how many people are actually going to do this? Probably the people who are already careful with their email addresses and passwords to begin with, the great ‘unwashed’ will not know how to enact such protections, it will literally be beyond their capability to successfully do consistently. Also with the Apple solution, you have to use Apple everywhere, which is another means of vendor lock-in.

So what is the solution? It’s actually quite straightforward, encrypt the email address at rest to the application level.

Email address encryption

If the email address is encrypted to the application (and not just at rest, see later) then only the application itself is able to make sense of the email address as stored. This is more than having the database encryption at rest turned on, as in such a case, if a hacker can get access to the database, the contents will be happily served up to the hacker decrypted, as the hacker will be pretending to be the application (i.e using the same database access credentials, say via a SQL injection).

Whereas, if the field or column that contains the email is encrypted by the application itself, access to the database will get you just the encrypted email, which will be useless to the hacker as a key to tie information together from other data breaches or to perform targetted phishing campaigns.

This need not be an expensive thing to implement, many implementations of strong two-way encryption exist. Also for quick lookup purposes, a distinct email hash column could be added (suitably algorithmically salted by the application) to speed things along (although do remember to check the encrypted email to protect against conflicts, don’t just assume the first match is the right one).

Remember, the goal here is if the database is copied out by a hacker, they will be missing critical information that will allow them to either reverse the hash or reverse the encryption of the email address. It will be effectively useless to them.

One thing to remember here is that the encryption occurs as the application level, no point just wrapping your database in something that does the encryption for you – for instance a transparent SQL proxy. This effectively does nothing to improve the risk profile, as a compromise at the database (or proxy) level connection still serves up the decrypted content.

Surely, this is overkill?

You may think it but look at all the sensitive personal data being lost via open databases and backups over the last few years. Everything from credit check histories and supporting evidence (Equifax) through to security logs (Marriott Properties) and medical records (AMCA). The ‘old mindset’ of building a strong wall around your data and you will be safe and secure no longer works with so much data being held in the cloud and exchanged. Consider encryption at rest to the application a form of Defense in Depth design, so even if the database is breached the damage caused is less.

Encrypt other unique identifiers

You should also consider encrypting at the application level other fields that can act as unique identifiers to tie together PII (Personally Identifiable Information), for instance:

• Telephone Numbers
• Account Numbers
• Driving licence and passport ID’s

Names and addresses can be sufficient to identify an individual but without a ‘cheap’ means of contacting that person (or pretending to be them), they have little utility to a hacker, plus are often in the public record already.

I cannot implement this…

It may indeed be that you are just a consumer of a product or service and have no direct means of enacting this. All is not lost. Service providers are all looking closely at PII security and what they can do to efficiently manage risks. This could be an ideal way for them to do just that.

The Regulatory Impact

Something else to keep in mind here is if you are able to use encryption to at rest ‘anonymise’ the PII fields in your database as stored, and a hacker was to make off with the database, and that field level encryption was strong enough, you might not be required to make a mandatory breach notification – as the hacker cannot possibly work out to whom the data relates.

In effect you have strengthened the confidentiality aspect of the security controls around what are PII field’s to ‘defang’ the risk of their exposure in the general case; i.e. the encrypted data on its own is not enough to reveal PII – the hacker needs knowledge of the encryption key(s), which if stored separately to the data in a way which is secure in itself, makes that unlikely.

Conclusion

If you store people’s email addresses in your computer systems and those computer systems are accessible via the Internet, I would strongly urge you to consider encrypting those email addresses (and other significant PII fields) at the application level. So in the unlikely event that you suffer a data breach of your database (or backup storage), the information obtained by the hacker will only have a weak association to an individual – making it of little use to them.

If you would like to learn more about effective management of PII in your computers, I suggest you read my book on the subject. This and other techniques are covered in depth.