Cryptography Stack Exchange is a question and answer site for software developers, mathematicians and others interested in cryptography. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I'm trying to find a good algorithm for generating authorization codes, access tokens and refresh tokens in an API.

Currently, I am looking into the following setup:

Tokens are generated using the RNGCryptoServiceProvider class in C#. (I have limited the allowed chars to the following set: abcdefghijkmnopqrstuvwxyzABCDEFGHJKLMNOPQRSTUVWXYZ0123456789!@$?_-)

Authorization codes are generated with 256-bit length and have a lifetime of 5 minutes. Access tokens are generated with 512-bit length and have a lifetime of 1 hour. Refresh tokens are generated with 2048-bit length and have a lifetime of 60 days.

Those codes and tokens are then salted with a random 64-bit salt, and then hashed using SHA-256 before being stored in the database.

Considering the token lifetime, salt and hashing algorithm used, would this be a reasonable secure setup?

share|improve this question
You don't need to go beyond the 256-bit length. 256-bit length is already considered secure for centuries. – SEJPM Oct 29 '15 at 12:18
Do you mean using SHA-256 is enough, or the random token is enough with 256 bit length? (Or both?) :-) Can I drop the salting since the token is random anyway? – azzlack Oct 29 '15 at 12:38
SHA-256 is OK, the tokens may be increased to 384-bit in size (considering you only have 6 bits of entropy per byte) anything beyond is pure overkill (even 256-bit length would be OK with 192-bit security). And you don't need to salt as your strings are high-entropy and salting is the counter-measure to fast low-entropy guessing. – SEJPM Oct 29 '15 at 12:45
@SEJPM Looks like you’ve got yourself an answer there. (Just saying…) – e-sushi Oct 29 '15 at 16:11
Completely agree, but how do I mark a comment as answer? – azzlack Oct 29 '15 at 16:19
up vote 1 down vote accepted

Your setup is secure. However it is largely "unneccessarily" secure.

First the generation method: You're using the RNG-CSP which is (I guess) Microsoft's software interface to the Windows secure PRNG, so this is fine.

Now for your tokens:
You're restricting the character set, which reduces the possible entropy per byte, but is fine if you're in a Web-Context. Note that you "only" have about 6 bits of entropy per byte (8 bits).
Your tokens are however too large. The standard security levels are 128, 192 and 256 bit security with 256 being considered secure as long as we're stuck in our solar system and don't discover any fancy energy source except our sun. Your current token sizes provide 192, 384 and 1536 bit security which is unneccessarily large in the latter two cases. I'd suggest changing the token's lengths to 384 bit. If you want, you can keep your short-time tokens at 256 bit or you can also raise the size if you feel 192-bit security (secure for a few decades at least) isn't enough.

Your choice of the hash is fine, SHA-256 provides 256 bit pre-image resistance which is just what you seem to want. Larger hash functions may be an option for you if you want to have more than 128-bit security against quantum computers, which would require you to use SHA(-3)-512

TL;DR: The long tokens may be shortened to 384 / 256 bit length, the rest is fine.

share|improve this answer

While SEJPM answered your question quite directly, please consider using stateless tokens instead. A token would be of the form identity_data||expiration_date, encrypted and authenticated using AES-GCM or perhaps ChaCha20-Poly1305. Your token is the nonce and cipher text concatenated and base64 encoded. Such a scheme prevents you from having to make a database query on every request, and prevents having to worry about replicating your session store database for high availability. All you need to do is distribute the key used for this token encryption to each server. The clients themselves act as your "token database", and your architecture is vastly simplified.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.