The One Man MMO Project: Designing to Mitigate Security Breaches
A few years ago I built a credit card processing system. It used 2048 bit RSA encryption to encrypt the credit card data on the customer's own computer, then stored the encrypted information on our server until the order could be processed. Then that encrypted data was transferred via floppy to a PC which was never connected to the internet where the decryption key was stored so the order could be processed. That system was pretty secure against outside breaches.
I had to shut it down when the credit card PCI data security standard came out because the cost of security auditing the software plus annual third party security audits for the rest of the company combined with the potential for $500,000+ fines levied by the credit card companies in the event of a security breach made it totally not worth the hassle and financial risk.
So I feel a lot of irony today with Sony saying this about their 77 million PSN accounts:
we believe that an unauthorized person has obtained the following information that you provided: name, address (city, state, zip), country, email address, birthdate, PlayStation Network/Qriocity password and login, and handle/PSN online ID ... profile data, including purchase history and billing address (city, state, zip) ... PlayStation Network/Qriocity password security answers ... your credit card number (excluding security code) and expiration date may have been obtained.
Wow. All that information. Apparently none of it encrypted. Too bad they're big enough that those PCI fines won't really hurt. I expect their security auditor will get hung out to dry.
The good thing about this disaster is that it got me thinking about intrusion security again. Here in Canada, in addition to PCI, companies also need to comply with PIPEDA the Personal Information Protection and Electronic Documents Act which has a lot to say about what data is stored and how.
Now I'm not a security expert, so if you're looking for expert advice, go hire an expert. I'm just talking about some of the guidelines I'm using while designing my own systems.
1) Don't collect any information you don't need.
This is sort of obvious, but stuff still seems to creep in. Marketing wants to know how old the players are. Management wants to know their annual income. Jimmy in the mailroom is doing a school project and wants to know their mothers' maiden name.
Just don't collect it. Do you really need more than your player's email address and a hashed password to serve them? Hire an outside firm to do surveys if you want to know more about your customers, they'll give you nice aggregate, anonymized data to use.
2) Encrypt the data you do collect.
Sony really didn't encrypt people's passwords? Really? Really???? Encryption is cheap nowadays, just do it. Store a salted hash of the user's password. Store a hash of the answer to their security question. Use a different encryption key for each piece of data. Don't store the encryption keys on public-facing machines.
3) Move the data farther from the internet.
Do you really need to keep their mailing address on a public-facing server? How about their customer service security question and answer? Move that stuff to a server off of the public network.
4) Back up your data, and keep old backups (but lock 'em up!)
Dump your database regularly and keep those old backups. When something goes wrong you'll be able to go back and see when things started to go badly for you.
5) Control who can access data, and log all accesses.
This one seems to be key for Sony. They claim they can't tell what the intruders actually got. If they had a decent auditing system, they would know. You want to be able to tell your customers exactly who lost what data and when.
Anyone who can access personal data should have to use their own login id to get it. If someone doesn't need access to personal data to do their job, they shouldn't have access.
6) Make sure users use good passwords.
With Sony storing passwords unencrypted, anyone who uses the same password for PSN and any other accounts has a problem. Password reuse is a very common problem and one we can reduce pretty easily.
One option is to have a password strength gauge which tells the user when they use a password in a rainbow table or a password that 94% of other users are using. If that gauge doesn't let them use total crap passwords, they are in a better position.
Another idea I've been toying with is to have the system make up hard passwords for the players. I think the key to this idea is to make hard passwords that the player can remember. One scheme I've always liked is to use the first letter of words in a saying or song lyric. "Tell me what you want what you really really want" turns into TMWYWWYRRW. Stick a number in the middle TMWYW5WYRRW and that's not a bad password. Try it, sing your favourite lyric in your head and type. That is easy.
Yes, if we insist on harder passwords, users are more likely to write their password down where their buddy can see it, but that's only one account, not every account they own, and you aren't going to lose 80% of your accounts to a dictionary attack.
There's one other really important guideline, but you can't really design for it:
7) Hire people you can trust.
The bulk of data breaches come from inside the network. Do a criminal record check. Make sure your employees are happy.
We were unable to retrieve our session cookie from your web browser. If pressing F5 once to reload this page does not get rid of this message, please read this to learn more.
You will not be able to post until you resolve this problem.
Copyright (C)2009-2015 onemanmmo.com. All Rights Reserved