Browse Prior Art Database

A system and method for generating tamper-proof tokens using a secret mixing blueprint and random salt for remotely controlling access to resources in a stateless resource server Disclosure Number: IPCOM000244660D
Publication Date: 2016-Jan-06
Document File: 8 page(s) / 101K

Publishing Venue

The Prior Art Database


Disclosed is a method in which the the Access Controller and the Resource Server share a secret blueprint for how to assemble the token text. Instead of merely juxtaposing the fields which constitute the token, they use a blueprint for how to break the individual fields into fragments and how to permute the fragments and sprinkle random salt bytes in between to generate a token text which when encrypted generates a dis-similar token even if the same input fields are used. This results in a more secure algorithm for access control on remote servers by reducing the vulnerability of manipulating or reconstructing access tokens

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 39% of the total text.

Page 01 of 8

A system and method for generating tamper -proof tokens using a secret mixing blueprint and random salt for remotely controlling access to resources in a stateless resource server



Resource Server (RS)

Resource User (RU) a.k.a client or user Access Controller (AC)

Token Validator (TV)


The existing approaches for generating access tokens to access resources on remote servers has the following limitations: • Same fields generate the same kind of tokens. If not the entire token, parts of the tokens resemble each other which makes it possible to spot patterns in the tokens and thus attempt to manipulate existing ones, generate fraudulent tokens by combining fragments from other tokens.

• When block ciphers are used for encrypting the token text, the output of a block of text will be the same if the portion of the token text constituting that part of the input (for ex. Resource url) is the same.

Use case & Scenario

The AC and RS have to pre-determine and agree upon the following:

1. Encryption Algorithm: The algorithm which will be used to encrypt the access token. This further leads to decisions like:

Symmetric / Asymmetric encryption

Mode of the cipher where multiple modes are possible
Key value and Initialization Vector (if applicable for the algorithm and mode)

The Key value and IV can be chosen at runtime whereas the others must be chosen at design time.

2. Hashing Algorithm: Whether the individual fields in the access token will be represented directly or will be hashed. If hashed then which algorithm will be used.

Use hashing/Don't use

Which algorithm
Output size of the hash
This decision affects the size of the token which is generated and also whether it will be fixed size or variable size.

3. Elements packed in the token: What all will be put in token ? For exampe: Resource being accessed
Methods/types of access allowed


Page 02 of 8


Other optional fields like User ID, Time to live/expiry

4. Mixing: This determines in what order and units the elements of the token will be combine while generating the token. For example whether Resource will be represented first or method.

Further for ex. different elements can be combined like this:
1st byte of resource - 1 byte of random salt - 2nd byte of resource - 1 byte of allowed methods - 1
byte of salt - 2 bytes of user id ......

This will increase the entropy of the generated token and make it hard to crack it even if a token
gets compromised.

5. Time to live - An optional field which will specify the validity of the token.

6. User Identifier - An optional field which will specify the user for which this token is issued.

Figure 1 and 2 explains the algorithm that can be used to understand the exemplar implementation


Page 03 of 8

Figure 1: Algorithm for generating token (Access controller side)


Page 04 of 8

Figure 2:Algorithm for deciphering token (Resource server side)

Exemplar implementation

1. For encryption, use AES 12...