On Sun, Dec 16, 2012 at 11:17:25AM -0800, Adrian Klaver wrote: > On 12/16/2012 11:07 AM, Peter Bex wrote: > > I don't know how Postgres stores its passwords internally or how > > its authentication works exactly. Maybe one of the developers > > can shine a light on this. > > http://www.postgresql.org/docs/9.2/static/encryption-options.html Thanks for the link; must've missed it somehow. I now also see the topic of improving the password hashing has been discussed before. For others reading along, I've found these two threads from this year: http://archives.postgresql.org/pgsql-general/2012-02/msg00334.php http://archives.postgresql.org/pgsql-hackers/2012-10/msg00462.php Like the poster in the first URL says, password hashing is *not* encryption. It's advisable not to refer to it as such - this will only help increase the widespread confusion about the subject. A good treatise on password hashing after the explosion of blog posts about "rainbow tables" is this one: http://chargen.matasano.com/chargen/2007/9/7/enough-with-the-rainbow-tables-what-you-need-to-know-about-s.html Note how it deprecates (salted) MD5 as insecure because they can be brute-forced too easily/quickly. I understand that it would take a lot for a database to be compromised and that the used passwords generally aren't going to be used on other sites. On the other hand, there's no guarantee of either, and it's not *that* complicated to improve the way passwords are stored. IMO, the simplest way to implement a good hashing system that can be easily upgraded in a backwards-compatible way when the need arises is to use modular Unix crypt(). Modern libc implementations provide a variety of decent ways of storing password hashes. I've collected some more information about UNIX crypt() in the documentation for a library I wrote for Chicken Scheme: http://wiki.call-cc.org/eggref/4/crypt All the fallback crypt() implementations this library provides are public domain, so they could be used in Postgres. If public domain is not acceptable for legal reasons, there are also plenty of BSD-licensed implementations to be found elsewhere; bcrypt was first implemented by OpenBSD. I could try my hand at providing a patch to switch to, say, bcrypt, but I'm pretty unfamiliar with the PostgreSQL source code. If nobody else is interested in working on it I can give it a try during the holidays. I'm not sure how to deal with the md5 authentication method. There is a good point in the -hackers thread above that eavesdroppers are probably able to hijack existing connections, but there's no reason to take any risks. One solution would be to point out in the manual that it's not secure and advise people to use SSL. Another would be to implement something like SCRAM, as pointed out in the -hackers thread I posted above or some other challenge-response system. However, this could be done separately, either before or after the password storage itself has been improved. Cheers, Peter -- http://sjamaan.ath.cx -- "The process of preparing programs for a digital computer is especially attractive, not only because it can be economically and scientifically rewarding, but also because it can be an aesthetic experience much like composing poetry or music." -- Donald Knuth -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
