Sony PSN compromise

We've all seen the news about Sony's PlayStation Network being compromised. It's bad enough the bad guys got personal information. It's worse that they got credit-card numbers. But it's downright unbelievable that they got passwords!

OK, first off: users are partly to blame. You shouldn't be sharing passwords between services. Whatever password you used for PSN shouldn't be used elsewhere.

But that doesn't excuse Sony. The passwords should never have been stored on the servers. Unix has handled that for years. It doesn't store your password, it stores a one-way cryptographic hash of your password. Remember that it doesn't need to know your password, it only needs to confirm that you know your password. So instead of storing your password it runs it through a cryptographic hash algorithm and stores the result. When you enter your password, it runs what you entered through the same algorithm and compares the result to the stored value. If you entered the right password, the two will match. If they don't, you didn't enter the right password. If you chose a strong algorithm it won't be feasible to take the stored hash value and reverse the process to get the original password, and there's no reason not to choose a strong (SHA-1 or better) algorithm since there's plenty of easy-to-use cryptography libraries out there (many of the best don't even cost money).

And credit-card numbers? In this day and age we should be able to do better verification of credit cards. Check ID for in-store purchases, for instance. But most fraud is on-line, you say? We can still do better. Requiring the CVV2 for all non-recurring purchases, for instance. Or linking your cel phone number to your credit card and using text messages to confirm the purchase. When a non-CVV2 charge is attempted, you get a text from the card issuer with details. You then have to text a charge ID code plus an authorization code (CVV2 or other set value) back to confirm the charge. No confirmation = charge declined. Now to make a fraudulent charge the bad guys not only need to get your card number, they need to clone your cel phone which means they need to know your cel phone number, SIM serial number and IMEI and they have to set up actual hardware. These guys operate wholesale, adding the time to do that work makes an 80-90% dent in the number of transactions they can run which pretty much hoses their business model.

Or better yet, for recurring payments go to a "push" or customer-originated payment system. So for PSN, instead of giving them your credit-card number and letting them initiate charges, PSN gives you a merchant account ID and transaction code. You go to your bank (or more likely to their Web site) and set up a payment to that merchant account for the amount required, using the transaction code as a reference number. Your bank then sends the money to PSN's account. End of most existing types of credit-card fraud, because merchants don't need to know any payment information anymore. The only thing you'd need a normal merchant-initiated charge for is over-the-phone purchases, and even then if you've got a cel phone the verification process above's possible.

So why are we still doing things the old-fashioned, fraud-prone way?

ASP.Net ViewState

Really really dumb idea: using a complex, high-overhead ViewState mechanism to set field values in the Web page returned from posting a form instead of simply setting the field values in the returned page. I mean, the posted page has the values populated, that's it's whole purpose. So when generating the response page, simply set the value attributes to what the fields' values were in the post request. Simple, no? Apparently not for Microsoft.