Sam Mason wrote:
Are you a cryptanalyst and are you sure that this doesn't actually make
things worse? I'm sure it gives you a warm fuzzy feeling that it's
*got* to be better, but unless someone has done some hard maths I'm not
sure how you can be so sure.
No sadly I am no cryptoanalyst.
Why not just use SHA-512, you get many more quality bits that way.
I would, if it was available in core.
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.
Sounds like a good reason for moving the current md5 function out into
pgcrypto as well! :)
I am not sure how I am to understand that comment. But again I am just a
user...
* I prepend the id and the username to guard users with weak passwords
against known hashvalues (rainbow tables) should the box ever get
comprised ...
I take it your threat model doesn't include the attacker logging
incoming queries to look for the clear-text password.
No it doesn't, I am mostly concerned with the grab and run scenario.
I am still convinced having more (and better) hash-functions in core is
a gain for some users.
And it is fairly un-intrusive as the hash functions are well-defined and
never going to change (new ones can be added and old ones deleted, but
SHA256 for example will never change).
I think I will drop the issue as I cannot present formal proof of my
case, sorry to have wasted your time.
Svenne
