dharga
dharga

Reputation: 2217

Token Generation Scheme Comparison

We're in the process of defining a time-sensitive token generation scheme for our SOAP services. Currently we have two ideas and we're not sure which is better and why.

Scheme 1:

The rands at the beginning and end don't add any particular value, but the idea is to add a small layer of salting.

Sender

<token>rand(6) ++ encrypt(time) ++ rand(6)</token>

Receiver

enc = token.substring(6,token.len-6)
time = decrypt(enc)
assert(time is within +/- range)

Scheme 2:

Here we encrypt the rands into the token.

Sender

<token>encrypt(rand(6) ++ encrypt(time) ++ rand(6))</token>

Receiver

dec = decrypt(token)
time = dec.substring(6,dec.len-6)
assert(time is within +/- range)

So I'm not only looking for an answer for which is best, but WHY it's best. I've looked for some documents or best practices, but short of IEEE documents, I haven't found much. If you have any documents you can point us to, we'd love that!

Upvotes: 0

Views: 44

Answers (1)

Brian Agnew
Brian Agnew

Reputation: 272347

Of the two schemes you present, the first doesn't really address the goal of salting. From Wikipedia:

The primary function of salts is to defend against dictionary attacks and pre-computed rainbow table attacks

and I would expect the salting to encrypt the same sequence differently each time you encrypt it. e.g. (using your examples)

  encrypt(rand(6) + encryptable)

such that multiple encryptions of the same sequence require individual decrypting.

If you need a unique token, rather than rely on a timestamp, why not use a GUID ?

Upvotes: 1

Related Questions