Does appending randomness to a token before encrypting it, make it more secure?

Scenario:

This is done because we need certain bits of information to be sent from the client to the server, but we don't want to leak those bits of information to the client because they would reveal details of the server's inner workings.

The issue here is that, every time a particular user views a particular page, the same token will be generated for them. Apart from allowing the same request to be replayed against the endpoint ad infinitum, this makes it more likely that someone will be able to break the token encryption (yes, I know this isn't likely, but it is possible).

To make the encryption even more resilient, my intention is to insert a high-quality random value - say a GUID - into the token before it is encrypted. The end result will be to introduce more entropy into the encryption process, meaning that for a given set of identical values that we care about (i.e. everything except the random value), the generated token will almost certainly differ. This random value will always be inserted in the same place and will always be the same length, so removing and throwing it away after the token is decrypted is trivial. Effectively, this is augmenting encryption with obfuscation.

It appears to my untrained eye that this is a relatively simple and safe solution to my problem, but is it, or am I just wasting my time and/or making things less secure and more complicated?

4 Answers
4

You don't need to add any randomness to an encrypted token. If it's properly encrypted, user has no way to infer anything about the encrypted data.

The issue here is that, every time a particular user views a particular page, the same token will be generated for them.

This seems odd. Your encryption does not seem to use a secure standard. Otherwise every time you encrypted the same token, the cyphertext would change. You must use an IV, and never ever think about AES-ECB, that mode is broken and should not be used even to teach kids how AES works.

If you use industry standards, you will know about the Initialization Vector (IV). In rough terms, the IV is a value added to the process that changes the cyphertext, so even if you encrypt two identical plaintexts with the same key, the corresponding cyphertext will change.

The IV is the random data you are thinking about adding. It's already there.

Let's try to break this down:

Problem: replaying a token:

Apart from allowing the same request to be replayed against the endpoint ad infinitum

Usually auth tokens solve this problem by expiring the tokens: the encrypted data includes a datestamp (which has the side-effect of making each token unique) and the server will reject any token older than, say 15 minutes.

Problem: breaking crypto:

this makes it more likely that someone will be able to break the token encryption

I'm not an expert, but it would seem to me that you should use a random IV for each encryption, and include the IV with the cipher text as part of the token. This would both solve the cryptanalysis problem you're alluding to, and have the side-effect of making your tokens unique. (if you're not using random IVs, then you probably have much bigger problems on your hands)

Why not use a standard library to do this rather than going out of your depth to design your own encryption scheme? I would recommend JWT.

Finally, as a public service I need to correct this: GUIDs ARE NOT HIGH-QUALITY RANDOMNESS.

See Wikipedia/Universally_unique_identifier.

UUIDs / GUIDs are designed to be unique, they make no attempt to be unpredictable. There are 5 standard ways to derive a UUID; 4 of them are some combination of MAC address + hostname + timestamp. Version 4 UUIDs are pure random, but because UUIDs / GUIDs generation needs to be fast and non-blocking, they use non-cryptographic random number generators.

PLEASE DO NOT USE UUIDs / GUIDs AS A SOURCE OF CRYPTOGRAPHIC RANDOMNESS. Instead use /dev/random in unix, SecureRandomin java, or whatever the equivalent is in your OS / programming language

/dev/random

SecureRandom

/dev/urandom

random

urandom

/dev/random

/dev/urandom

The solution that is used on my platform of choice is "encrypt/decrypt with managed IV (Initialization Vector)." What this means is that, upon encryption, the entire plain text is encrypted with a cryptographic secure IV, and then the IV is placed in base64-format before the beginning of the cipher text. Upon decryption, the IV is pulled off the front and used as the IV for the cipher text. This is all transparent to the developer. Note that it is perfectly safe to expose the IV, because decryption with the correct key but wrong IV will result in a failure condition. If your programming language has a similar feature, do use it; by having a random IV generated each time you encrypt something, you don't need to put any extra data in the plain text.

To me, this looks like an XY Problem.

The best way to protect a secret is not to tell anyone the secret. The token is generated server-side. The server already knows the data. And then you replay the token to the server, which contains only data the server already has. That is completely unnecessary.

Other answers have pointed out the quick, immediate fix for your encryption problem by using encryption with IVs. But the better solution would be to make this superfluous.

Server builds up token using various values, encrypts it (via an industry-standard algorithm, nothing homegrown) using a key only the server knows, and returns it as part of the page data

Instead of encrypting those values, save them in a database. You can potentially, if you really must, still encrypt those values and then save them. But there is absolutely no need for these values to ever leave the server, even in encrypted form.
Then generate a truly random token (with a CSPRNG), and use that as a lookup-key. Send this token to the client.

Token is embedded into link on page

Use the random token you just generated for that.

When client clicks that link, token is sent to server, decrypted and parsed and the values used to determine what to do

Instead of decrypting and parsing the values, you use the token to look them up in the database. Done. If you only stored the data encrypted, you still need to decrypt it, of course.

This also works if you have multiple servers. If the token is generated on Server A and send to Server B, have Server B use a secure connection to Server A and request the data via the token from Server A. In this scenario, too, the data is never sent to the client.

This is done because we need certain bits of information to be sent from the client to the server, but we don't want to leak those bits of information to the client because they would reveal details of the server's inner workings

Internal state should never leak from an implementation. This is already a code smell and a good hint that your architecture is flawed.

Required, but never shown

Required, but never shown

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.