Hiding token information from users

[Tobiah]

I am making QR codes that cell phone users scan in order
to make use of an application. Part of the information
is a token that needs to be passed on to the server, but
I'd rather not allow a person examining the QR code to
be able to see that plain bit of information. I'd like
to scramble up the token so that the result:

1) takes up the same (near, or less) number of characters as the
original token.

2) They key can be derived from the input, and vise versa.

3) The result is alphanumeric.

4) When one character changes in the source,
many characters are likely to change in the
result.

So if my token is:

mytoken2011

The result might be something like:

xm23ffz4uuw

Then
mytoken2012

might yield something very different:

d8ru3jdhvhd

I was thinking of just stringing up all letters and
numbers into a 'wheel' and doing an 18 char rotation on
the chars in the token, but that fails #4. The secret is not like
the key to Fort Knox. We would rather not have the plain
token out there, as it's internal business information,
but we don't have to protect the information at all costs.
Just making it really inconvenient to extract is fine.

Thanks,

Tobiah

 

[Tobiah]

How many of these codes do you need, and do they only need to be
decrypted at a central server? You might be able to just create random
strings of whatever form you want and associate them with the tokens in
a database. Then they will be completely opaque.

The tokens have a year portion that increments each year, and
the base portion of the token will be created newly in accordance
with new accounts that we take on. I really need some sort of
algorithm that will let me take an unknown string and generate
the encrypted bit on the fly.

Thanks,

Tobiah

 

[Steven D'Aprano]

I really need some sort of
algorithm that will let me take an unknown string and generate
the encrypted bit on the fly.

Google broken for you? *wink*

Seriously, there are about a bazillion algorithms for encrypting and
obfuscating strings. Depending on your security requirements, that can be
as simple as rot13 and as complex as blowfish (or even more so).

If it helps, I have a module that implements a selection of classical (i.e.
insecure) encryption algorithms:

http://pypi.python.org/pypi/obfuscate


Earlier, you said:

The secret is not like
the key to Fort Knox.  We would rather not have the plain
token out there, as it's internal business information,
but we don't have to protect the information at all costs.
Just making it really inconvenient to extract is fine.

I don't understand the point of this. What could your users do with the
plain token that they shouldn't? I don't see why, if it's not worth
encrypting properly, why it's worth obfuscating it at all.

 

[Tobiah]

Google broken for you? *wink*

I had some requirements in the OP that I could not
find a solution for.

Seriously, there are about a bazillion algorithms for encrypting and
obfuscating strings. Depending on your security requirements, that can be
as simple as rot13 and as complex as blowfish (or even more so).

If it helps, I have a module that implements a selection of classical (i.e.
insecure) encryption algorithms:

http://pypi.python.org/pypi/obfuscate


Earlier, you said:


I don't understand the point of this. What could your users do with the
plain token that they shouldn't? I don't see why, if it's not worth
encrypting properly, why it's worth obfuscating it at all.

The token ends up translating into the name of a database on our
server. With that information alone, it's difficult to imagine
a serious vulnerability, yet we just thought it would be worth
it to disguise the plain text.

 

[Nobody]

I am making QR codes that cell phone users scan in order to make use of an
application. Part of the information is a token that needs to be passed
on to the server, but I'd rather not allow a person examining the QR code
to be able to see that plain bit of information. I'd like to scramble up
the token so that the result:

Can you not just encrypt the data with a fixed secret key?

A fixed key satisfies #2.

#3 can almost be satisfied by using base-64, or can be entirely satisfied
by using base-36 or base-62 (these are less efficient, but that doesn't
matter for small amounts of data).

#1 can be satisfied by compressing the text beforehand; this should almost
exactly compensate for the expansion caused by #3.

Any block cipher in CBC mode will satisfy #4 (it will even be satisfied in
ECB mode if the compressed token is smaller than the cipher block size).