Protection From Inference (was Re: Drawbacks of using BYTEA for PK?)

Greg Stark wrote:
> ...  worrying about leaking information like the size of the
> customer database is usually a sign of people hoping for security through
> obscurity.

To prevent the size of your database being guessed at from the serial 
numbers of your customers' accounts, don't issue the numbers sequentially.

One simplistic method of non-sequential assignment is: generate a random 
number between "00...00" and "99...99"*, check if it's already in use - 
if not, issue it, if so, regenerate.  When presenting the number, always 
format it as an N-digit number with leading zeroes - for Perl 
programmers, this would be achieved along the lines of printf("%010d", 
$account_number)

Thus you will end up with customer numbers evenly spread over the number 
space. This will prevent people inferring the size of your database (or 
company) through the account numbers they observe.

To protect the customer's account from being accessed by unauthorised 
persons, use form-based password access (not HTTP basic**) and/or X.509 
certificates over a secure connection.

As Scotty says, "use the right tool for the right job!"

HTH
Alex Satrapa

*make the number space much larger than your expected number of 
accounts. This reduces collisions in random number generation. Another 
option is to increment through the number space in the event of a 
collision, rather than generating another random number.

**using form-based access, the user can log out when leaving the 
terminal. Using HTTP basic, the browser is likely to remember their 
login for the entire session, and sometimes even between sessions.