bugtraq - Re: [HACKERS] Postgres: pg_hba.conf, md5, pg

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Fri, 22 Apr 2005 21:02:21 +0100
From: Antoine Martin <antoine@...afix.co.uk>
To: Bruno Wolff III <bruno@...ff.to>
Cc: Tom Lane <tgl@....pgh.pa.us>,
	"Jim C. Nasby" <decibel@...ibel.org>, pgsql-hackers@...tgresql.org,
	bugtraq@...urityfocus.com
Subject: Re: [HACKERS] Postgres: pg_hba.conf, md5, pg_shadow, encrypted
	passwords


On Thu, 2005-04-21 at 17:27 -0500, Bruno Wolff III wrote:
> On Wed, Apr 20, 2005 at 22:27:01 -0400,
>   Stephen Frost <sfrost@...wman.net> wrote:
> > 
> > SHA2 would also be nice.
> 
> I think the new hash functions are called SHA256 and SHA512.
> For Postgres' purposes the recent weaknesses found in SHA1 and MD5
> aren't a big deal.
It is irrelevant here, if I am reading this correctly:
http://theory.csail.mit.edu/~yiqun/shanote.pdf
"collision search attacks"
Basically, multiple input data that have the same output hash, which is
of no use when what you are trying to find is the input.
Finding collisions quicker for a known input is one thing, but that is
not going to reduce the search space, not even your storage space (it is
unlikely that the colliding results would all be valid input).

Is adding the non-guessable salt that hard anyway?