How to generate account number?

[Andriy Kornatskyy]

Requirements for `account number` generator:

1. Issue pseudo random consistent number (must be unique for dozen millionsof records)
2. Easy check validity (without a need to make a database call)

Interested? Read more here:

http://mindref.blogspot.com/2012/11/generate-account-number.html

Comments or suggestions are welcome.

Thanks.

Andriy Kornatskyy

 

[Steven D'Aprano]

Requirements for `account number` generator:

1. Issue pseudo random consistent number (must be unique for dozen
millions of records)

How much randomness do you need? From the perspective of any one user, a
simple incrementing counter returns arbitrary values, which may be "close
enough" to random.

last_num = 103872 # Pick an arbitrary starting value.
def get_account_number():
"""Return the next account number."""
global last_num
last_num += 1
return last_num

Stick that value in a database instead of a global, and you're done.

What are the consequences of people guessing account numbers? If the
consequences are serious, then you need to make account numbers
cryptographically strong. If the account number alone is not important,
then you don't.

2. Easy check validity (without a need to make a database call)

Add a check digit to the number you generate. There are all sorts of ways
to do that. Here are two examples:

http://code.activestate.com/recipes/577692
http://code.activestate.com/recipes/577691

Interested? Read more here:

If you ask a question here, please keep the discussion here, don't split
it to your personal blog.

Tell us your requirements in more detail, and we will try to help you.

 

[Andriy Kornatskyy]

'ef764a2fe44532008dc9a99c391c70cd85ec9d82'

It is too long and not verifiable.

UUID('2c14484b-5a0c-4f4b-b7bc-8187548b4888')

Pretty much the same what you suggest but simpler and shorter. Not quite elegant for humans.

Here are examples per this post:
http://mindref.blogspot.com/2012/11/generate-account-number.html
'Z07395350007'

Short, human readable and satisfy original requirements.

Andriy


----------------------------------------

 

[Andriy Kornatskyy]

Steven, see below, please.

----------------------------------------

From: (e-mail address removed)
Subject: Re: How to generate account number?
Date: Fri, 2 Nov 2012 22:39:31 +0000
To: (e-mail address removed)



How much randomness do you need? From the perspective of any one user, a
simple incrementing counter returns arbitrary values, which may be "close
enough" to random.

last_num = 103872 # Pick an arbitrary starting value.
def get_account_number():
"""Return the next account number."""
global last_num
last_num += 1
return last_num

Stick that value in a database instead of a global, and you're done.

What are the consequences of people guessing account numbers? If the
consequences are serious, then you need to make account numbers
cryptographically strong. If the account number alone is not important,
then you don't.

Yes. There are consequences to not use sequential numbers, yet humans deal with it (enter as input somewhere, etc). The approach suggested here:

http://mindref.blogspot.com/2012/11/generate-account-number.html

is using Feistel cipher to generate pseudo random thus makes guessing account numbers hard (impossible?).

Add a check digit to the number you generate. There are all sorts of ways
to do that. Here are two examples:

http://code.activestate.com/recipes/577692
http://code.activestate.com/recipes/577691

These tell me how to verify some code, but doesn't how to generate it. The approach suggested here:

http://mindref.blogspot.com/2012/11/generate-account-number.html

gives you ability to customize `sample_f` function to make it unique to your business case.

If you ask a question here, please keep the discussion here, don't split
it to your personal blog.

The question was rhetorical with my answer in the blog and discussion here to reach something.

Tell us your requirements in more detail, and we will try to help you.

I have presented solution to `account number` challenge. So it was share with community and seek for thoughts if any.

 

[Roy Smith]

'Z05738521581'
'Z17888279480'
'Z07395350007'

Short, human readable and satisfy original requirements.

Andriy

If you really want human readable, it's better to chunk the data up into
3 or 4 digit groups. So, instead of Z05738521581, maybe
Z05-738-521-581. Or perhaps even better, Z05-7385-21-581 (just a hunch,
but I suspect varying the length of the groups makes it easier to read).

Even better might be base-32 encoding the value. Strings of digits have
an information density of about 3.2 bits/char. Base-32 is just about as
readable, but gives you 5 bits/char, so you end up with a few less
characters (which you still want to chunk into 3 or 4 character groups).

 

[Tim Chase]

Even better might be base-32 encoding the value. Strings of
digits have an information density of about 3.2 bits/char.
Base-32 is just about as readable, but gives you 5 bits/char, so
you end up with a few less characters (which you still want to
chunk into 3 or 4 character groups).

For things that will be read off a screen/paper, I recommend
omitting several letters that are easy to mistake visually: i/I/l/1
and O/0 in particular. The VIN (vehicle identification number) on
all US cars avoids these characters[*], making it easier to read
them back without concern for "is that a zero or an oh; and is that
an ell, a one, a lowercase eye, or a capital eye?" As an encoding
advantage,
string.digits) if c not in "O0iIl1"))
32

the number 32 is pretty handy when dealing with binary

-tkc


[*]
The VIN avoids "Q" too and does use the digits 0/1, but the idea
holds. Make it easy to ready back.

 

[Andriy Kornatskyy]

Roy,

Per your advise:

from base64 import b32encode
human_format = lambda n: 'Z%s-%s' % (b32encode(chr((n >> 24) & 255) +chr((n >> 16) & 255))[:4], b32encode(chr((n >> 8) & 255) + chr(n & 255))[:4])
human_format(5738521581) 'ZKYFA-4PWQ'
human_format(17888279480) 'ZFI4Q-PO4A'
human_format(7395350007)

'ZXDGA-CX3Q'

Side by side:

Z05738521581 = ZKYFA-4PWQ
Z17888279480 = ZFI4Q-PO4A
Z07395350007 = ZXDGA-CX3Q

Thanks.

Andriy


----------------------------------------

 

[Andriy Kornatskyy]

Tim,

Good point. b32decode seems to be capable to understand such common mistakes (see map01 argument to b32decode), I haven't tried:

http://docs.python.org/2/library/base64.html

Thanks.

Andriy

----------------------------------------

Date: Sat, 3 Nov 2012 10:34:26 -0500
From: (e-mail address removed)
To: (e-mail address removed)
Subject: Re: How to generate account number?
CC: (e-mail address removed)

Even better might be base-32 encoding the value. Strings of
digits have an information density of about 3.2 bits/char.
Base-32 is just about as readable, but gives you 5 bits/char, so
you end up with a few less characters (which you still want to
chunk into 3 or 4 character groups).

For things that will be read off a screen/paper, I recommend
omitting several letters that are easy to mistake visually: i/I/l/1
and O/0 in particular. The VIN (vehicle identification number) on
all US cars avoids these characters[*], making it easier to read
them back without concern for "is that a zero or an oh; and is that
an ell, a one, a lowercase eye, or a capital eye?" As an encoding
advantage,
string.digits) if c not in "O0iIl1"))
32

the number 32 is pretty handy when dealing with binary

-tkc


[*]
The VIN avoids "Q" too and does use the digits 0/1, but the idea
holds. Make it easy to ready back.