From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Marko Kreen <marko(at)l-t(dot)ee> |
Cc: | Michael Fuhr <mike(at)fuhr(dot)org>, Russell Smith <mr-russ(at)pws(dot)com(dot)au>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: contrib/pgcrypto functions not IMMUTABLE? |
Date: | 2005-07-03 16:57:54 |
Message-ID: | 5745.1120409874@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Marko Kreen <marko(at)l-t(dot)ee> writes:
> On Sun, Jul 03, 2005 at 12:02:38PM -0400, Tom Lane wrote:
>> That doesn't seem like a good idea at all. Why shouldn't an encryptable
>> value be NULL? I think you should just make 'em strict.
> Well, I have mainly issues with decrypt part. I'd like
> to say, if decrypt succeeds, whoever put the data there,
> had the key. Existing decrypt() has a smell of it - there
> is 1/256 chance that data modification won't be detected.
And that has what to do with throwing an error on NULL input?
> As for the crypt() case, lets say you have a new user with
> hashed password field NULL. In addition, you have client
> program that compares crypt() result with hashed field
> itself, in addition it handles NULL's as empty string.
> Result: it is possible to login with any password.
> Lots of assumptions but in eg. PHP case they are all filled.
A NULL password field is intended to have exactly that effect, no?
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Marko Kreen | 2005-07-03 17:15:07 | Re: contrib/pgcrypto functions not IMMUTABLE? |
Previous Message | Marko Kreen | 2005-07-03 16:52:17 | Re: contrib/pgcrypto functions not IMMUTABLE? |