Hi Daniel:
On Sun, Jul 19, 2015 at 9:03 PM, Daniel Verite <daniel@manitou-mail.org> wrote:
> For SERIAL, it's too obvious to guess what is the next one,
> so malicious people could claim access codes or vouchers
> they don't own.
Why don't you use encryption? Specifically only on the external side.
You use a serial in the DB and send the encrypted serial as voucher
code ( this way you do not need to have database resident encryption
). Then when you receive the code in the program you decrypt it and
are done. And having serial in the DB can be good for your internal
operations. Encryption, reversible and colision free, not hashing.
> The constraint is that such codes must be reasonably short, but
> someone who tries to make up one must have a near-zero chance
> of guessing one that actually exists.
If you can live with a little longer voucher ( it seems you use 10^9
in random ), you can use 2^32, which is just 9.5 digits, and search
for a 32 bit block cipher ( or build it yourself, it's not that hard
using stream ciphers or other tools ).
I also thinks random UUIDs are not ok, not because they are long but
because they are random, and can collide ( encrypted serials can not
).
Francisco Olarte.
