Re: Unique code for every user

From:

=?ISO-8859-1?Q?Arne_Vajh=F8j?= <arne@vajhoej.dk>

Newsgroups:

comp.lang.java.programmer

Date:

Tue, 06 Oct 2009 21:14:28 -0400

Message-ID:

<4acbeb74$0$293$14726298@news.sunsite.dk>

Arne Vajh?j wrote:

Barry wrote:

On 6 Okt, 15:28, Barry <magnus.morab...@gmail.com> wrote:

On 6 Okt, 15:20, Leif Roar Moldskred <le...@huldreheim.homelinux.org>
wrote:

Barry <magnus.morab...@gmail.com> wrote:

Thie problem with this though is that the user with the code
100-000-003 can easily guess that 100-000-004 is also a code for
another transaction. What would be a better way to generate this
number?

Is there any reason why you can't just add a password and only allow
users to retrieve data for their own transactions?

Yes, there is a reason. I will print a receipt with the unique code on
it, which they will enter when they return to the system via a touch
screen keypad. Asking the user to enter their own Id is not an option.
Also, my system has no way of knowing if two transactions belong to
the same user or not. Infact, my system has no knowlege of users only
transactions.

A simple way to think of the system is that of a safety deposit box.
The user gets a unique id when they enter they belongings in it, and
use this key to open it again. The thing is, I don't want people
opening other peoples boxes.

This problem is very similar to session id in secured web applications.

Based on that I will suggest:
- hash the sequential key
- store the hash value server side and lookup based on that

Hashes is designed to make it difficult to go from hash to
original value.

Note though that both hashing and the symmetric key ciphers
are painfully vulnerable to brute force attack if the algorithm
is known.

It does not take long to hash or encrypt all values 0-999999999
find ones own obfuscated id and apply the algorithm to the next.

As an absolute minimum you should pick the id's randomly.

Arne