Can I provide an encrypted string to users and be sure it is safe for 1-2 hours

Question

We were making kind of a simple game, in which:

• Users receive the next number of play as an encrypted string Before they play
• After they play, the encryption password is provided to them to check the play number was correct.
• Each encrypted string is only valid for 1-2 hours and number of play , verificating string and encrypted string is regenerated again after that time
• The encrypted string includes a verification (5 char) code so both users and we can make sure Decryption process was successful

Sample Character to get Encrypted (QQ9LU is random verification code provided to user before the play):

Next Play Number: 8 - Verify String: QQ9LU

Sample Encrypted String (provided to user before play):

NXRykKOv3B6kuu4Ke3svp7HH3enNiqIZrJSXJiF54QkHHjtXgqpUXxyuP7YUNICeFLg==

Sample Password (provided after play):

Please note this is generated randomly for each encryption

FA00RDjA77hlOzcOzH6kuGcc29CyM7Hw

We use CodeIgniter 2.2.2 Encryption Class to encrypt/decrypt strings

Encryption Method Info:

• Function Used: $this->encrypt->encode($msg, $pass); with random pass each time
• Cipher is CodeIgniter 2 default MCRYPT_RIJNDAEL_256
• Mcrypt mode is MCRYPT_MODE_CBC

My Questions are:

1. Can i trust that users cannot break the encrypted string (and know the number of play before they get the password) in 1-2 hours (aside from getting lucky)

2. Is placing random verification code Verify String: T3YH4 in there good or bad? does is affect security? (this is to verify decryption result was successful, also we added it because the only variable in each string was a single digit, for example only number 8 changes to 7, so we wanted to add more variable characters to the string to possibly have a better security)

Any other suggestion is appreciated

Answer 1

Short answers:

1. From a technical POV, what you're doing is unsafe, although it might be enough for just a 2-hour timeframe.
2. What you're trying to do here is called "message authentication", but that's not how it should be done, which in turn does impact security. You should use a HMAC instead.

My advice would be to upgrade to CodeIgniter 3 (CI2 will stop receiving even security updates in a few months) as soon as possible, and use its new Encryption library instead. That will make it safe for years, not hours.

Long answer:

The encryption library should do both encryption and authentication for you, but unfortunately the CI_Encrypt class itself is badly written and lacking a lot of functionality (such as authentication), which is why it was DEPRECATED and is being replaced by a new (CI_Encryption) library in CodeIgniter 3.

Explaining all the flaws in here would be quite the task, so I'd rather link you to an external article (not self-promoting, don't worry), which does that quite nicely if you're interested in the low-level details.

No matter which library you use however, one thing must be noted - a password is not the same thing as an encryption key.

Passwords have a varying length and are used by humans, which means that they must be readable by humans, and that in turn limits them to a certain set of characters.

Encryption keys on the other hand have a fixed length (each encryption algorithm is designed to work with a specific key length; for Rijndael-256 that's 32 bytes, which you seem to match) and are not limited to human-readable characters (which means more entropy and therefore more security) - they represent raw binary data.

Anything else can be controlled (and therefore automatically done) by a library, but if you pass a password instead of a key - that's what the library will use, so you should take care of that.

Answer 2

The best and simple way to do that is to use the filesystem functions to create a simple text file for each user in non public path with two lines, the first of them is a unique random string (long string varied in length) and the second is the number.

Then using sha1_file get the hash value of the file then store it in the database related to its path and creating time, then send this hash to the user.

After the user has played, check the value by another script that get the value of the hash from the database, then read the file and parse its second line to display the number.

By this way, you have gave the user a hash not for a string, but it for a file and cracking it to get the file back is not simple as to be done in two hours.