On Wed, Aug 15, 2012 at 10:22 AM, Joe Conway <mail@joeconway.com> wrote:
> On 08/15/2012 06:48 AM, Tom Lane wrote:
>>> On Wed, Aug 15, 2012 at 6:11 AM, Bruce Momjian <bruce@momjian.us> wrote:
>>>> Is there a TODO here?
>>
>> If anybody's concerned about the security of our password storage,
>> they'd be much better off working on improving the length and randomness
>> of the salt string than replacing the md5 hash per se.
>
> Or change to an md5 HMAC rather than straight md5 with salt. Last I
> checked (which admittedly was a while ago) there were still no known
> cryptographic weaknesses associated with an HMAC based on md5.
There is no cryptographic with md5 either really. The best known
attack IIRC is 2^123 (well outside of any practical brute force
search) and the algorithm is very well studied. The main issue with
md5 is that it's fast enough that you can search low entropy passwords
(rainbow tables etc) which does not depend on the strength of the
hashing algorithm. 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.
The sha family are engineered to be fast and are therefore not
meaningfully safer IMO. Ditto NIST hash function (upcoming sha-3)
that Andrew is mentioning downthread (that might be a good idea for
other reasons but I don't really think it's better in terms of
securing user password). If you want to give the user good password
security, I think you have only two choices:
1) allow use hmac as you suggest (but this forces user to maintain
additional password or some token)
2) force or at least strongly encourage user to choose high entropy password
A lot of people argue 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.
merlin