Although the latter part of this post discusses Always Encrypted in SQL Server 2016, I’m starting with the topic of protecting your own credit cards. I have a certain credit card that will remain nameless that we use for as many purchases as possible because of the cash rebate it offers. It’s like electronic cash to us and always paid in full. Because of my card’s widespread use, it seems to get compromised about every 10 months. Fraudulent charges appear and I end up spending some amount of time on the phone affirming that a whole bunch of charges were fraudulent. The credit card issuer removes the fraudulent charges, cancels the old card, and sends a new card.
The problem with using one card for everything is when you have preauthorized payments for things like insurance and utilities. Having your card cancelled is very bad for preauthorized payments. You can end up with late fees or service disruptions when a scheduled payment is attempted against a cancelled card. My wife and I got tired of this problem and adopted a new strategy. I have a card and she has a card from the same issuer offering the same cash rebate. Her card is used exclusively for preauthorized payments. My card is used exclusively for everything except preauthorized payments. Her card has never left the house. When my card was last compromised, it was cancelled. Since our preauthorized payments were tied to her card, they weren’t affected. We avoided the inconvenience in logging on to a dozen websites and providing new credit card data.
SQL Server 2016 has a new encryption feature Always Encrypted. It’s well suited for encrypting credit card numbers in a database. It’s perfect for when you want to store encrypted data and keep even the all powerful DBA from seeing the actual unencrypted data values. Read more about Always Encrypted here.