Tag Archives: security

Dear Livejournal,

Your password security requirements are retarded. Apparently, my new password, that you literally forced me to pick, is half the length of the original password. It's somehow more secure because it contains punctuation (with an attacker not knowing that or not, they would be forced to try punctuation, numbers, etc, just because it was possible), but seriously, there was no way in hell my previous password would be guessed by an automated system or human being. It was a strung together sentence.

Stupid. Stupid. Stupid.

Oh well.

Love, Paul




More than 40 million credit card numbers belonging to U.S. consumers were accessed by a computer hacker and are at risk of being used for fraud, MasterCard International Inc. said yesterday.

In the largest security breach of its kind, MasterCard officials said all credit card brands were affected, including 13.9 million cards bearing the MasterCard label. A spokeswoman for Visa USA Inc. confirmed that 22 million of its card numbers may have been breached, while Discover Financial Services Inc. said it did not yet know if its cards were affected.

Proceeding down the walk of shame now is CardSystems, Inc., a merchant services provider.

For those of you unfamiliar with how credit card processing works, let me give you a quick rundown. Forgive my shitty ASCII art, it's late.

You -> Merchant (merchant either swipes or keys in the number, or if online, retransmits it over SSL to the payment processor) -> Payment Processor (optional, if online – they act as a terminal for you – this is part of the merchant step, really) -> Merchant services provider & Merchant account bank -> Magical credit card interchange system -> Cardholder bank. Then the cardholder bank does a test to see whether the credit limit, amount requested, and all that jives. If the bank is willing to render that payment to you, it returns success, along with an authorization code. If not, it returns a decline with a reason code (my favorite one is "Pickup", which indicates that not only was the card declined, but you should attempt to seize it if you can do so safely).

(If that last part was confusing, my payment processor, Authorize.net, has a pretty little diagram of how it works, simplified, for online transactions)

Then the request goes back to the merchant services provider, who records the transaction as an authorization (and usually a capture too), and then passes the success or fail to you. If you do things like address verification or checking of CVV2, those are usually done at this point, and if they don't match, the transaction is reversed, meaning that you've just created a bit of hell for some poor debit card guy who won't see the hold drop off his account until you batch out.

Anyhow, so the merchant services provider stores a log of all transactions, not only to assist in fraud correlation, but to actually finish the transaction, which occurs in three stages:

  1. Authorization – This actually is where you stake your claim to a specific amount of money, and ask the bank if it's available. Say if I'm pumping gas, I may authorize you for $50 before I turn on the pump, just to make sure that if you hit that, your card can cover it. Restaraunts typically authorize your card for 125%-150% of the bill, to cover tip if you write one.
  2. Capture – In many transactions, this is done at the time of authorization. In things like hotel rooms, self service gas pumps, restaraunts, etc, this is done at the end of the transaction. The amount you capture cannot exceed your authorized amount. If you authorize for $50, and capture for $25, it only takes $25 from the customer's bank account. No actual withdrawal is generally done unless you do a capture. But most of the time, say, getting groceries, buying crap off amazon, etc, this is done simultaneous to the authorization (which is known as an authorization and capture transaction).
  3. Batch – All your captured transactions are held until the batch they are associated with is closed. Typically this occurs daily. Most merchant providers will refuse a batch older than 60 days, so this is often done at least every other day even if you don't do many transactions. The batch actually initiates the transfer of money, which was just set aside for you when you captured. Typically, at this point, the money is enroute, and if you refund someone, or void a transaction, it runs as a withdrawal of your account, a seperate transaction rather than just reversing the one that was already done.

For investigations of chargebacks, or fraud, the merchant provider keeps a full record of the transaction. If someone were to get ahold of this database, the results could be disasterous.

Guess what. It just happened. Endgame.

Let's see how this ends up.