On Thu, Jul 27, 2006 at 15:15:32 +0200,
Tomasz Ostrowski <[EMAIL PROTECTED]> wrote:
>
> * PostgreSQL integers (as returned by nextval()) are 4 bytes. This
> means only 32 bit strength - much too low for today computers.
They are actually 8 bytes. Since session ids aren't valuable for very long
Alvaro Herrera wrote:
Tom Lane wrote:
* 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.
Yeah, it's not clear where to hide the secret.
In a memfrob'ed
On Thu, 27 Jul 2006, Tom Lane wrote:
> Tomasz Ostrowski <[EMAIL PROTECTED]> writes:
> > * When somebody knows md5('secret_salt' || '5') he will be able to
> > easily compute
> > md5('secret_salt' || '50')
> > md5('secret_salt' || '51')
>
> Sure, but can't you fix that by putting the secre
I'm not an expert as you, but what about a small table where just one
user can read and create the function with this same user and definer
security?
Excuse if I say something stupid
Alvaro Herrera wrote:
Tom Lane wrote:
* Any database user is most of the time able to read function
bodie
Tom Lane wrote:
> > * 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.
>
> Yeah, it's not clear where to hide the secret.
In a memfrob'ed (or someth
Tomasz Ostrowski <[EMAIL PROTECTED]> writes:
> * When somebody knows md5('secret_salt' || '5') he will be able to
> easily compute
> md5('secret_salt' || '50')
> md5('secret_salt' || '51')
Sure, but can't you fix that by putting the secret part at the end?
> * PostgreSQL integers (as
> > 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')
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' || n
Tomasz Ostrowski wrote:
On Wed, 26 Jul 2006, Tom Lane wrote:
"Antimon" <[EMAIL PROTECTED]> writes:
As the id field is primary key, it should generate a unique violation
if duplicate ids created, might be seen rarely but wanted to solve it
anyway.
Why don't you just use a serial generator?
I
On Wed, 26 Jul 2006, Tom Lane wrote:
> "Antimon" <[EMAIL PROTECTED]> writes:
> > As the id field is primary key, it should generate a unique violation
> > if duplicate ids created, might be seen rarely but wanted to solve it
> > anyway.
>
> Why don't you just use a serial generator?
If I may int
"Antimon" <[EMAIL PROTECTED]> writes:
> As the id field is primary key, it should generate a unique violation
> if duplicate ids created, might be seen rarely but wanted to solve it
> anyway.
Why don't you just use a serial generator?
So i decided to check it by changing "sid := md5(random());"
11 matches
Mail list logo
