Skip site navigation (1) Skip section navigation (2)

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: (view raw, whole thread or download thread mbox)
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:

  Bruce Momjian  <bruce(at)momjian(dot)us>

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

In response to

pgsql-admin by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group