Better Credit Card Security

While talking with a friend, who is enduring some unpleasantness the conversation turned to issues with using credit cards to buy things, like food for example. That got me thinking, how would I design a really strong way to prevent data breaches?

Encrypt everything!

Well, perhaps not that, but hash everything. Here’s what I talked myself into, of course none of this is rational because nobody will effect a planetwide shift in payment processing based on what this yokel has to say, but still, here goes.

Issuing Bank sets up credit account, there are four key fields that are important for the classic transaction, name, number, expiration date, and CVV2. I think one could also establish a timebased one-time-password secret as well, it would operate like Google Authenticator functions. So you’d need a secret that the bank generated for their systems and the physical card too. You’d need a smart chip on the card so it could forward the TOTP code to the credit terminal at the point of sale.

The bank sets up a TOTP secret, so it’s named JQP Credit Card (or account number or whatever) and the secret is: 6B57078FB88A4DD73E447D2647DCEC7D04C3D887951BA6A2D8DBA294E0B60579. This number is forwarded to the credit card terminal. Right now it’s 726995, but in thirty seconds it’ll be something else. Since the credit card terminal and the bank share sync’ed time via time.nist.gov, there is no risk that there would be some sort of mismatch between the two.

The customer goes to the credit card terminal and swipes, a value is entered and a timestamp is recorded, all of this is already parts of a credit transaction. The terminal can read the name, expiration, CVV2, whatever from the magnetic stripe and the smart chip forwards the TOTP code, then the terminal assembles this into a EDI transaction:

JOHN/Q/PUBLIC#1111222233334444#1015#170#726995 and applies SHA256 to it, to create:

621d3dd5a66277a7ab3737f306728e3c4bc5f3cd20c8730c37cc61c6575de0ba

This is stored in a database and then forwarded to the bank with the timestamp, so it’ll look like this:

987654321#621d3dd5a66277a7ab3737f306728e3c4bc5f3cd20c8730c37cc61c6575de0ba#15.09#1426615839

So the bank will be presented with a Customer ID, SHA-256, they’ll have the total dollar amount, and they’ll have Epoch time, or the number of seconds from 00:00:00 UTC, January 1, 1970. This could be easily done by a Linux kernel by the output of date -j -f “%a %b %d %T %Z %Y” “date” “+%s”

The bank would then have everything they need, they’d have the secret key, which with the Epoch time from the transaction would give them the TOTP calculation, which would generate the answer 726995. Then they’d have the card details from the customer ID, the SHA-256, and the amount. They could then calculate the hash on their own:

621d3dd5a66277a7ab3737f306728e3c4bc5f3cd20c8730c37cc61c6575de0ba

And authorize the transaction.

Even if the card details were stolen by someone copying the numbers off the card, they wouldn’t get the TOTP secret. Plus the TOTP secret is changing every 30 seconds. If someone tried to run this transaction and guessed at the TOTP code, they’d generate this:
987654321#a1b714fba988632200c78a5b9021bca5b48f149b036aa901c03173f0f2de5399#15.09#14266158 and the bank would instantly detect this incorrect SHA hash and cancel the card and ship a new one.

This is rather involved but the practical upshot is, if a vendor kept these transactions in a database and someone stole the database to use for their own nefarious needs, the presence of the TOTP and SHA-256 would make the data in the database worthless because the TOTP has no predictable pattern if you don’t know the secret, and SHA-256 is very sensitive to even the smallest change in the input data that it’s hashing. This would free vendors, banks, and customers from risking PII leakage or identity theft.

I’ve also thought that this would be a great way to secure SSN’s as well for use with the government, they know your SSN and you know your SSN, so when communicating over a possibly compromised channel you can authenticate not with your SSN, but with the hash of your SSN.

John Q. Public, 123-45-6789 -> 01a54629efb952287e554eb23ef69c52097a75aecc0e3a93ca0855ab6d7a31a0

Google Authenticator

Dial lockOver the long Fourth of July holiday weekend I received an email from WordPress.com detailing news that they were now fully compatible with the Google Authenticator Two-Factor security system. I haven’t thought of Two-Factor in a long while and decided to look into how Google had cornered the market in this particular security market.

First a little background. The term Two-Factor security means that when you want to prove who you are to some service, called authentication, you usually just have to present two pieces of information, a username and a password. This combination not only identifies who you are and proves your identity through the shared secret of the password, but allows systems to remain as open as possible to all clients who want to connect – assuming that everyone is playing by the rules and nobody is trying to be sneaky or clever. Passwords are notoriously wimpy things, most people give up on complexity because they can’t readily remember the password and it’s not convenient so they select simple passwords like “12345”, “password”, or “secret” and leave it at that. The problem with passwords is that people who make them up are either lazy or don’t care about entropy or complexity and since a lot of your work and identity is being controlled using these systems, using these simple passwords is begging for disaster. Another issue that plagues a lot of people, and goes in with how naturally lazy many of us are, is that people will use one poor password on every site they go to and keep their usernames the same as well. The risk here is that when one service is compromised, all the other services are compromised as well and it’s a huge upward climb to get out of that mess if you find yourself trapped in it.

Cleverness works both against people in general, with thieves, phishers, and hackers as well as for people in general, with things like hashapass or applications like 1Password. Hashapass is a free service that combines the web address of a service with one single complicated password to generate a hash, which is to say, a value that is easily calculated from the combination of the single complicated password and the web address but done so in a way that going backwards is very difficult to do. If any piece of the puzzle is missing, it’s technically unsolvable. As an alternative to this there is 1Password, an application that I have become very fond of, and it uses a similar approach to hashapass. In 1Password one master password unlocks a database of all the sites and their individual passwords so you don’t have to remember a constellation of passwords, all you need is to remember one very good secure password and you are all set. There are a few other nice features to 1Password that I like, being able to generate very long random passwords and store them for me allows me to establish plausible deniability when it comes to my online identities. Because 1Password randomly selected a 32-character password for Facebook, I cannot be compelled, even under torture to reveal that password to anyone else. I just don’t know it. I know 1Password, but that’s not the right question so my account remains secure.

All of this I have collected and use, and I use it everywhere. On my MacBook Pro, my iMac at work, my iPad and my iPhone. 1Password makes it very easy to manage the security database and I’m quite sure that it’s secure. In my life, any more security is rather like putting more padlocks on a firmly locked jail cell, it’s rather silly and feels a lot like overkill. Then again, more security is always better, especially if it’s really clever and somewhat convenient.

Two-Factor security adds another component to the process of authentication. It augments the username and password combination. A password is something I know (or store using 1Password) and the second factor is something called a Time-Based One Time Password (TOTP). This is where the free iPhone app called Google Authenticator comes in. The app records a secret key from a site I wish to prove my identity to in the future, for example, Google itself. I set up two-factor, request a security token for Google Authenticator and set it up in the app. The key is transmitted by QR code, which means you can quickly acquire the long complicated random (hard to type) secret key using the camera in your phone. Once this process is complete the Google Authenticator app displays a six digit number that will work to prove your identity to the site associated with that particular entry and this entry only exists for 30 seconds at a time. This six digit password exists only once in any one 30-second period and there is no way to divine this password without having the Google Authenticator application with it’s stored secret code.

Having two-factor enabled in this way means that my username and password are no longer as important as they once were. Even if my username and password are revealed or compromised without my knowledge, the secret key that I have in my Google Authenticator app remains secure with me and the 30-second-long one-time-password additions remain a secret with me. What I know may be compromised, but what I have (the Google Authenticator) most likely won’t be unless someone steals my phone and finds a way to best the security on that device before I have a chance to wipe it remotely. If in the case my Google Authenticator becomes compromised, my passwords will likely not be because they are uncrackable, and so I am still secure.

Practically how does this work? When I want to log into Google Mail using two-factor, this is what I do. I open a web browser, I type in the address “gmail.com” and press enter. Then I enter my username and my password and then in the third field under the password is a box labeled “Google Authenticator Token” and then I grab my phone, start my Google Authenticator application and then read the six-digit number from my phone and type it in. The service logs me right on and after a few seconds, that six-digit password is no longer valid and is meaningless. I’m authenticated and the system did as it was designed to do. One of the nice parts of Google Authenticator is that the entire app is a mathematical operation, it doesn’t require the network at all to generate these numbers, so this would be a good solution for people who may not have a reliable connection to the network or have a data quota on their phone.

Of course, online authentication is just the beginning. I found a way, yesterday, to embed the Google Authenticator system into my Mac OSX Mountain Lion installation so that when I want to login to my computer at work or my laptop I have to type in my username, my password, and read the six-digit code from my Google Authenticator application. The setup isn’t difficult to get it to work. You need a compiled PAM module which I have (just ask if you want a copy) and an application which you use to create the secret key on your computer. With it all set up, and a slight adjustment to a settings file, even if I were to lose security on my password at work nobody could login to my account without my username, password, and GA token.

This arrangement works quite well and I’ve set it up for my Google accounts, my WordPress.com and .org blogs, Facebook, Evernote, and Dropbox accounts as well. Everything is secure, obnoxiously secure. 🙂

photo by: MoneyBlogNewz