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
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 |