seanmonstar

Apr 1 2014

Please Replace Credit Cards

Technology has greatly improved things this past decade. It’s peculiar that messaging nonsense has seen so much work, but something that quite literally costs people money continues to be so flawed. I’m talking about credit cards. It’s worth pointing out that I’m not a security researcher, just a concerned citizen.1

The flaw is a fundamental part of the design: for every charge, we must give the entire card number to the seller. That card number is everything. It gives all the information and power to charge as much money as the recipient wants. Holy carps. The sellers don’t charge as much as they want, because that would be illegal, and they’d lose their merchant account. Still, employees could keep the number and sell it. Or, more likely, as sellers keep a record of the number, hackers can steal them, and get all the moneys. Until you notice, report fraud, and the banks just swallow it.

One supposed fix is the Swipe-and-PIN enhancement. This helps prevent copying of a card at a Point-of-Sale terminal. However, advances in magic (the Internet) have greatly increased the amount of online shopping. Want a new spiked collar for Fluffles? Just open your browser, and type in your credit card number. Nothing to worry about, I’m sure they won’t record it. Oh what’s that? An email from Exotic Collars that their database was hacked, and they actually did have your credit card. Time to call the bank, and fix up all your auto-billing subscriptions.

You get a token, and you get a token…

We can try to create rules around how to store credit cards, but just like passwords, it’s really hard to do correctly. Also, just as with passwords, merchants should never receive such powerful information in the first place. A solution could be providing the merchant a one time use token authorized for a specific amount for a specific merchant. The merchant charges the token, and it then becomes useless. It’s impossible to charge for more than agreed upon. Stealing the token is useless, because it only works for that merchant, it expires, and a credit account will only accept any token once.

If the source card or key which is used to generate tokens is compromised, a user can contact their credit provider, and generate a new private key. No merchants are affected, since they never had your key to begin with.

Recurring charges would be trickier. It’d require more cooperation among banks, standardizing some sort of unique account ID. Tokens could include the account ID, and merchants could safely hold onto that. When they need to make a new charge, they could request a new token for a certain amount. The user can approve the charge which sends a new token, or perhaps mark that a certain amount from a specific merchant every so often is auto-approved. I’m sure plenty of things could be done here to make the user experience easy. And there’s incentives for as easy as possible: Easier means users will spend more.

Credit accounts could provide apps to their users to make sending and approving tokens easy from our phones. Additionally, the app could also optionally prompt for approval when a merchant charges a token, to ensure there was no mistake or the token wasn’t somehow hijacked2.

Stand back, I don’t know crypto

I’m certain smarter people than myself could make a really secure design, but I’ll entertain you by stumbling around with mine. The implementation could look something like Persona. The tokens passed around could be JWTs. It could follow something like these steps:

  1. A merchant could ask a user account for a token, including details like items purchased, total amount, and a merchant ID, with the blob signed by their private key.
  2. The user sees the charge request, sees the details match the signed blob, and approves it.
  3. The user’s account includes the original request, the user’s ID, and a signed blob using the user’s private key. This JWT would be sent to the merchant account.
  4. The merchant account would then submit the token to credit company.
  5. The credit company would verify the user’s blob against their current public key, and verify the merchant’s blob against their current public key.
  6. Optionally request final approval from user.
  7. Transfer specified amount of money from user’s account to merchant’s account.

It would take a lot of work to move the world over to this system, but the end result should be much more secure. It should mean much less fraud, and much fewer stories like what recently happened with Target. Can we please do this?


  1. Or, I have no idea what I’m talking about. 

  2. The design reduces the risk of a stolen token, since it’s generated for a specific merchant. However, it could be that a hacker gets control of a merchant account, or their private key, and can claim to be the merchant. 

Mar 25 2014

Your Password is Insecure

We know that you should have a unique, sufficiently-long, sufficiently-randomized password for every property that requires one. We also know that if you most likely don’t do this whatsoever. There’s no way we’re going to change users’ habits. So this is the reason why we need to get rid of passwords.1

You may think the danger exists with someone guessing your password at your bank, or your email account. Instead, those websites have teams of professionals who spend their whole working day keeping out hackers. That’s not where the danger starts. The danger starts at a tiny e-commerce site, or webforum, or other small-scale site. Some site where you’d think “I don’t care if this account is stolen.” Those are the dangerous sites. Even if you think your password is a pretty good one, because it doesn’t contain any personalized information, and looks like gibberish: if you use the same password, then your password is as weak as the weakest site you use it at.

What really happens: a mom-and-pop shop that sells honey decides to sell more via a website, and has you log in to remember your shipping address. They’re not security experts. They didn’t hire any either. A hacker aims for sites like those. The hacker only has to get passed the minimal security of Honey Buns, to find a list of e-mails and passwords. Maybe the passwords aren’t even hashed; they’re just sitting there in plain text. You shouldn’t be worried that the hacker can ship an insane amount of honey to your house. They wouldn’t bother. Instead, they will take that list, and try each e-mail/password combo on important sites: Wells Fargo, Bank of America, Gmail, Paypal, etc. You used the same email and password on one of those sites as you did with Honey Buns? Then the hacker has just successfully logged in as you, and it mostly looks like a normal login. They then transfer money to their account, and carry on.2


  1. I’ve been explaining this to anyone who has asked me about Persona and passwords, and figured it’d be nice to have it in a linkable quotable location. 

  2. Of course, those sites try to protect against this too. They might notice the IP address is from a completely different part of the world. And they might prevent dangerous actions from that IP until you’ve confirmed another e-mail challenge. But the point still stands. 

Oct 4 2012