Re: User password encryption using a stronger hashing function?

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: "ktm(at)rice(dot)edu" <ktm(at)rice(dot)edu>
Cc: lst_hoe02(at)kwsoft(dot)de, pgsql-admin(at)postgresql(dot)org
Subject: Re: User password encryption using a stronger hashing function?
Date: 2012-02-11 00:59:13
Message-ID: 20120211005913.GB25379@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-admin

On Wed, Dec 28, 2011 at 08:25:54AM -0600, ktm(at)rice(dot)edu wrote:
> > >If you have a need for stronger hashing functions you might want
> > >to contact one of the consultants who does contract work on
> > >PostgreSQL development and find out what'd be involved in funding
> > >the development of the feature. Think about why you need it first,
> > >though; what threat(s) are you trying to protect from?
> >
> > The reasoning is that if your Database content get lost your
> > passwords are in danger to be decrypted todays with md5 hash and
> > most of the time passwords are reused at other places. With stronger
> > hashes at least the password itself would be somewhat safe. But as
> > said in many environment the application does not use database users
> > anyway, but does its own user management with hopefully stronger
> > encryption of the passwords.
> >
> > Thanks
> >
> > Andreas
> >
> Exactly. You need to use GSSAPI or something else to secure it. Then
> the passwords are not available to be decrypted in the database and
> you can use much more extensive encryption for them.

The limitations of MD5 do not apply to the way we use MD5 to store
passwords in Postgres; see:

http://archives.postgresql.org/pgsql-hackers/2008-01/msg00846.php

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ It's impossible for everything to be true. +

In response to

Browse pgsql-admin by date

  From Date Subject
Next Message Wissem 2012-02-12 17:01:35 Automatic Failover Hot Standby / Streaming replication
Previous Message Kevin Grittner 2012-02-10 15:15:04 Re: 32-bit to 64-bit migration options