There’s a scary item recently in a Database Weekly newsletter. Apparently your credit card number code can be guessed in seconds. Using techniques that spread guesses around to a number of sites, criminals can avoid triggering alarms, which makes some sense. I would hope that banks would find ways to patch this quickly as I’d expect that some central system should be providing authorization. However, since banks haven’t shown much inclination to adopt DevOps and move quickly when required, perhaps I’ll be changing my credit cards every quarter this year instead of just once.
Perhaps a new card that can change numbers make sense. There is a technology that could change the actual digits on a card. That reminds me of the RSA SecurID VPN cards that I used to carry with a number that changed every minute. The current number was required to log into VPN and you only had a minute to enter it. I had expected this might be required more and more, but it seems relatively few companies implemented the system. I know some companies have moved to software based token systems, and certainly two factor authentication has become more widespread, but not as widely as I’d have hoped.
However, no matter what is implemented, anything that is widespread, easy to use, and predictable, will likely be cracked. While I could see banks wanting to verify each charge somehow, that might be unwieldy in today’s highly cobbled together, distributed systems. The move to machine learning and more intelligent data mining can help, but when criminals try to make charges that don’t cause simple flags to be raised, what will banks do then? I think we will see more intelligent criminal attacks that avoid machine learning algorithms, especially when there criminals get organized and focus on digital attacks.
I don’t mean to get caught up in the specifics of credit card numbers. I’d rather think more widely about the issues of data leakage and how information can be extracted from any mechanism that we use to try and secure information. Look at the Dynamic Data Masking (DDM) feature in SQL Server 2016. It’s a great feature in some ways, and as a convenience for developers, this makes sense. However, for determined attackers, there are easy ways around this. Query for a specific value, and SQL Server processes the query, even if the result returned to you is masked, you’ll know the underlying value. There are similar holes in Row Level Security, giving intelligent hackers the ability to determine what data is in your tables.
I think ultimately some of the ways in which we can protect our individual data come from being able to analyze query patterns. Machine learning and an integration with the Query Store maybe helpful in performing this analysis. If we know what queries we expect from a system, then we can detect anomalous behavior, which may let us know there are attacks being performed. While we might not be able to prevent all information from being disclosed, being aware and limiting future access can be valuable in preventing the impact of a data breach from growing too large.