Number Security

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.

Steve Jones

The Voice of the DBA Podcast

Listen to the MP3 Audio ( 4.6MB) podcast or subscribe to the feed at iTunes and Libsyn.

About way0utwest

Editor, SQLServerCentral
This entry was posted in Editorial. Bookmark the permalink.

2 Responses to Number Security

  1. Geoff Hiten says:

    Having seen how the sausage is made (that is – I have done work in the Credit Card processing space), having rapidly changing card numbers is not exactly a viable solution. The assumptions in the system design just won’t easily allow that. I am not talking about implementation, I am talking about basic assumptions on how the banks, processors, and merchants tie together. The card numbers will likely remain fixed, but with a rotating, encrypted challenge-response authorization code embedded in the consumer card/device, much like the RSA token except hidden in the guts of the transaction. Perhaps with a second factor that is user-supplied. That is something that can be implemented with current technology and architecture.

    The biggest challenge will be in Point-of-Sale devices. Many of these are over a decade old. Vendors want to sell new systems while merchants don’t want to spend money on a new “cash register” when the old one works just fine. Nobody wants to upgrade an embedded system. Just getting chipped cards in place was a major undertaking that required rewriting fraud liability laws. Even so, there are still merchants that only swipe.

    Finally, I agree with you on not getting caught up in the specific tech when discussing security. No single technology is the “holy grail” of security. Just like High Availability, security is a mixture of people, process, and technology that is ever evolving.

    • way0utwest says:

      Good points. I’m amazed how many US merchants still don’t do chips yet. Lots have devices, but no software. We’ll see if things improve in the next few years. I hope so.

Comments are closed.