Re: [GENERAL] SHA1 on postgres 8.3 - Mailing list pgsql-hackers

From Svenne Krap
Subject Re: [GENERAL] SHA1 on postgres 8.3
Date
Msg-id 47F50EEC.8070008@krap.dk
Whole thread Raw
In response to Re: [GENERAL] SHA1 on postgres 8.3  (Mark Mielke <mark@mark.mielke.cc>)
Responses Re: [GENERAL] SHA1 on postgres 8.3  (Andrew Dunstan <andrew@dunslane.net>)
Re: [GENERAL] SHA1 on postgres 8.3  (Sam Mason <sam@samason.me.uk>)
List pgsql-hackers
Mark Mielke wrote:
>> More two or even three different hashes with different collion-points 
>> will strongly increase the security.
> No it doesn't unless you are thinking about a security through 
> obscurity argument.
It is really the same argument on all your questions....

If I have a simple table now

ID serial
Username varchar
Password varchar

I currently save only md5(id || username || 'password')*  into password, 
if I had access to sha1 (for example) i would add another password 
column so, having for example

ID serial
Username varchar
Password_md5 varchar
Password_sha1 varchar

No matter how you see it, I get more bits of hash to check against.

I would drop md5 totally and use sha1 and ripemd-160 if possible.. but 
currently i use only md5 as it is the only available one..  Loading 
pgcrypto is overkill for something as simple as hash-functions.

Svenne

* I prepend the id and the username to guard users with weak passwords 
against known hashvalues (rainbow tables) should the box ever get 
comprised ... if you are in doubt about the value of this, try google 
for 40e94aa51dc5c0ccc5aad4e6aefdde2a and guess the secret password...


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Small TRUNCATE glitch
Next
From: Tom Lane
Date:
Subject: Re: [GENERAL] ANALYZE getting dead tuple count hopelessly wrong