-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160
> If the hacker has access to the salt, then it will only slow
> him/her down somewhat because the search will be have to be
> restarted for each password.
This. Further, anyone using MD5 or SHA* or any hash function for
any serious storage of passwords is nuts, in this day and age.
GPUs and rentable cloud computers means the ability to test billions
of passwords per second is easy for anyone, salted or not.
The issue is not Postgres' internal use of MD5 for passwords - that's
a red herring, as it is basically no more relatively secure/insecure
versus any other hashing algorithm that is not designed to be
slow (e.g. bcrypt, scrypt, PBKDF2). The issue is simply exposing a
more useful day to day algorithm by default. Much of the world uses
SHA instead of MD5 these days for all sorts of purposes.
So I am torn on this. On the one hand, having a few more things in core
would be very nice, as it seems silly we have md5() as a builtin but
sha256() requires a special module. But once you add sha* in, why not
AES? Blowfish? Why not go the whole way and include some extremely
useful ones such as bcrypt? At that point, we've deprecated pg_crypto
and moved everything to core. Why I personally would love to see that
someday (then we can boast "built-in crypto" :), I recognize that will
be a very tough sell. So I will take the addition of whatever we can,
including just a sha() as this thread asked for.
> 3) use a purposefully slow hashing function like bcrypt.
>
> but I disagree: I don't like any scheme that encourages use of low
> entropy passwords.
Perhaps off-topic, but how to do you figure that?
- --
Greg Sabino Mullane greg@turnstep.com
End Point Corporation http://www.endpoint.com/
PGP Key: 0x14964AC8 201208201849
http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8
-----BEGIN PGP SIGNATURE-----
iEYEAREDAAYFAlAywBwACgkQvJuQZxSWSsiS4QCbBC7X9MyQgVKC3DTKgjv0aj7D
ik0AoNh1YBmhuaMXEKOP7z/GEBUR+EHe
=54A2
-----END PGP SIGNATURE-----
