Jump to content

  • Log In with Google      Sign In   
  • Create Account


#ActualDave Weinstein

Posted 29 April 2013 - 07:00 AM

So, XOR is meaningless. Really, seriously, honestly, you might as well ROT-13 it, meaningless.

 

Here are some basics on cryptography for data-at-rest.


One, don't write your own. Just don't go there. Get a tested library, use that.

 

Two, in an ideal world, you want to be able to swap out your crypto algorithm if a problem arises in it. So your code shouldn't be deeply tied to the cryptographic routine you are using. This is generally termed "crypto-agility".

 

Three, salts and hashes. So, a cryptographic hash is a one way conversion. You take a value (say, a password), and you generate a hash of it. In order to get the original from the hash, you would have to just generate values until you got one that matched the same hash (more on this later). You then store the hash in your database (so you never keep the actual plaintext of the password in your database). A salt is a value that you derive deterministically from the account (whether it is intrinsic to the account or simply a random value stored with the account) that you add to the password before hashing it. What this does is mean that if Bob has password "123456" and Alice also has password "123456", they still have different hashes in your database. Otherwise, if I hash "123456", I can immediately get every account that used that password. On the other hand, if I get your database, and I want to get Bob's password only, it doesn't make a difference.

 

Which brings us to four, hashes continued. Counter-intuitively, you want to use *slow* algorithms for hashing when you are picking your algorithm. The reason for this is that you can afford the extra time to hash a password on login, but you make it much harder for someone to brute force things. Remember how we said you'd have to algorithmically generate strings until we got our hash again? That's why you want a slow algorithm (ex. bcrypt).

 

Now most of what I just said only applies to the password.


Storing other information is also important, and can have real legal repercussions depending on where the servers are located (for example, if you were suddenly running on a server in the EU, you fall into EU privacy laws), and if you start dealing with Credit Cards you have all sorts of contractual headaches about data storage. The easiest way to secure data is not to have it, so always consider whether or not you need a piece of information at all.

 

If you are storing it, consider what parts of your server actually need it, and when, and keep the data encrypted at rest. You may want to have the service that actually needs that information on a separate server (one that doesn't handle the untrusted input that is user interactions on a regular basis), such that even if someone were able to get control of the game server, they wouldn't be able to pivot to get the user information.

 

And finally, I am not a cryptographer. It is entirely possible that I made an error, especially since I'm just jotting this post off, and I'm certainly not a lawyer.


#1Dave Weinstein

Posted 28 April 2013 - 10:54 PM

So, XOR is meaningless. Really, seriously, honestly, you might as well ROT-13 it, meaningless.

 

Here are some basics on cryptography for data-at-rest.


One, don't write your own. Just don't go there. Get a tested library, use that.

 

Two, in an ideal world, you want to be able to swap out your crypto algorithm if a problem arises in it. So your code shouldn't be deeply tied to the cryptographic routine you are using. This is generally termed "crypto-agility".

 

Three, salts and hashes. So, a cryptographic hash is a one way conversion. You take a value (say, a password), and you generate a hash of it. In order to get the original from the hash, you would have to just generate values until you got one that matched the same hash (more on this later). You then store the hash in your database (so you never keep the actual plaintext of the password in your database). A salt is a value that you derive deterministically from the account that you add to the password before hashing it. What this does is mean that if Bob has password "123456" and Alice also has password "123456", they still have different hashes in your database. Otherwise, if I hash "123456", I can immediately get every account that used that password. On the other hand, if I get your database, and I want to get Bob's password only, it doesn't make a difference.

 

Which brings us to four, hashes continued. Counter-intuitively, you want to use *slow* algorithms for hashing when you are picking your algorithm. The reason for this is that you can afford the extra time to hash a password on login, but you make it much harder for someone to brute force things. Remember how we said you'd have to algorithmically generate strings until we got our hash again? That's why you want a slow algorithm (ex. bcrypt).

 

Now most of what I just said only applies to the password.


Storing other information is also important, and can have real legal repercussions depending on where the servers are located (for example, if you were suddenly running on a server in the EU, you fall into EU privacy laws), and if you start dealing with Credit Cards you have all sorts of contractual headaches about data storage. The easiest way to secure data is not to have it, so always consider whether or not you need a piece of information at all.

 

If you are storing it, consider what parts of your server actually need it, and when, and keep the data encrypted at rest. You may want to have the service that actually needs that information on a separate server (one that doesn't handle the untrusted input that is user interactions on a regular basis), such that even if someone were able to get control of the game server, they wouldn't be able to pivot to get the user information.

 

And finally, I am not a cryptographer. It is entirely possible that I made an error, especially since I'm just jotting this post off, and I'm certainly not a lawyer.


PARTNERS