Marko Kreen <marko@l-t.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 ---------------------------(end of broadcast)--------------------------- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly