Posted by Robert Schifreen on October 23, 2015.
There’s much talk in the media at the moment about the latest attack on telecoms company TalkTalk. The company says it’s possible that information on all of its 4 million customers could have been stolen by hackers, and the information includes bank and credit card account data. It also sounds as if the information was not encrypted, which has resulted in many people asking why it wasn’t. Surely it’s simple to encrypt data in an online system?
Actually, sadly, it’s not that easy. Which is no excuse not to do it, but it’s not as simple as it might seem.
Let’s assume that your system consists of 2 main components. Firstly, a database of customer information. Secondly, some code which accesses that database and allows the user to interact with it, via an app and/or a traditional web site.
Some database systems offer something called TDE, or Transparent Data Encryption. Enabling it is often as simple as ticking a single box. The database engine now ensures that everything in the tables is sufficiently scrambled. This happens outside of the code component, hence the transparent part. The code sends some data to the database, and it automatically gets encrypted without the code having to do anything. Similarly, the code requests some data, and it comes back unencrypted without the programmers needing to decrypt it. The programmers don’t even need to know the password (and in some cases, the system actually doesn’t even tell them).
Although this is a good solution, it does have drawbacks. It isn’t supported on all database systems, for a start. Microsoft SQL Server has it, but MySQL doesn’t. Secondly, what happens to data in transit, ie when it’s travelling between the application or web site and the database engine? It’s not encrypted, so a hacker could intercept it.
The other way of handling encryption is for the program code to do it. When the program wants to store information in the database, it encrypts it first. Then it sends that data to be stored. Equally, to retrieve data from the database, the code requests it, the information gets retrieved, and then the code has to decrypt it. This, too, has drawbacks. For a start, all that encryption and decryption takes time because there’s complex maths involved. Secondly, how do you run a query on the database such as “show me all the users whose surname is smith” when the word “smith” no longer appears in the database in plaintext? You’d have to retrieve every record, decrypt it, then scan it. And with 4 million subscribers, that’s not quick. Finally, if you do decide that your code is going to handle the encryption, where do you store the password that it will need to use? In the code itself? Somewhere else on the server that the code runs in? Either way, if the server or the code is compromised, all that encryption is a waste of time.
There are many other aspects to be considered too. If your database is going to store encrypted information, you lose the concept of a column containing text, or numbers, or strings. You don’t even know how long each field is going to be, because “smith” might require 200 characters to store in its encrypted form. So your neat schema goes out of the window and you end up with tables full of binary blobs. Which you can only access via your own code, which knows how to decrypt it. Looking at the data in phpMyAdmin will serve no purpose.
So yes, encrypting customer data can, and should, be done. But before you say “surely it can’t be that hard”, consider the possibility that actually it might be.
Submitted in: Robert Schifreen |