On Wed, Aug 15, 2012 at 10:22 AM, Joe Conway <m...@joeconway.com> wrote: > On 08/15/2012 06:48 AM, Tom Lane wrote: >>> On Wed, Aug 15, 2012 at 6:11 AM, Bruce Momjian <br...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
