Re: Generating unique session ids

From: Tomasz Ostrowski <tometzky(at)batory(dot)org(dot)pl>
To: Lexington Luthor <Lexington(dot)Luthor(at)gmail(dot)com>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: Generating unique session ids
Date: 2006-07-27 13:15:32
Message-ID: 20060727131532.GB15258@batory.org.pl
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Thu, 27 Jul 2006, Lexington Luthor wrote:

> >Session id's for web cannot be predictable because this will create a
> >security hole in application.
>
> Using a sequence does not mean it will be predictable.
> In the past I have used something similar to this:
>
> SELECT md5('secret_salt' || nextval('my_seq')::text)

* When somebody knows md5('secret_salt' || '5') he will be able to
easily compute
md5('secret_salt' || '50')
md5('secret_salt' || '51')
md5('secret_salt' || '52')
...
md5('secret_salt' || '59')
md5('secret_salt' || '500')
md5('secret_salt' || '501')
...
md5('secret_salt' || '[any number starting from 5]').
Without knowledge of 'secret_salt'. So your proposal is totally
insecure.

* PostgreSQL integers (as returned by nextval()) are 4 bytes. This
means only 32 bit strength - much too low for today computers.

* Any database user is most of the time able to read function
bodies, so anybody who is able co connect to your database will be
able to get your 'secret_salt' and then predict session id's.

* If you think that nobody will connect to a database but
web-application frontend there's a high probability of SQL-injection
hole in frontend, which is sufficient.

So, basically, a very bad idea.

Regards
Tometzky
--
...although Eating Honey was a very good thing to do, there was a
moment just before you began to eat it which was better than when you
were...
Winnie the Pooh

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Chris Mair 2006-07-27 13:34:16 Re: Generating unique session ids
Previous Message Adrian Klaver 2006-07-27 13:11:00 Re: JDBC