Re: Encoding passwords - Mailing list pgsql-general

From Bruce Momjian
Subject Re: Encoding passwords
Date
Msg-id 200109271858.f8RIwbA01970@candle.pha.pa.us
Whole thread Raw
In response to Re: Encoding passwords  (Lincoln Yeoh <lyeoh@pop.jaring.my>)
Responses Re: Encoding passwords
Re: Encoding passwords
List pgsql-general
> I personally use encoded password= hash( concat(salt,password)), and store
> both the salt and the encoded password. Where hash = sha1 or md5.
>
> The DB columns are: salt, encoded password, encoding method.
>
> Note that apparently there are some cryptographic weaknesses with
> concatenating the salt and the password with the salt in the front, the way
> I did it unfortunately :). If I recall correctly, if the salt is short then
> attackers only need to attack a subset of the full hash. The salt being a
> known plaintext. So some say to concat with the salt at the back. I suspect
> a long salt should make the attack far less feasible, or alternatively
> XORed the salt with the password or maybe hash multiple times.
> Unfortunately I can't seem to find the original article.
>
> I haven't got around to changing my apps. It's not too bad since the fields
> allow for different encoding methods - for this reason I suggest you have a
> field to store the encoding method too.
>
> So you can have 'NONE' or 'SHA1' or 'MD5' or 'SHA1B' and so on.
>
> That said if hostile people get to the stage where they can read the
> encoded passwords, you're probably screwed anyway - they're likely to be
> able to do other things some even more undesirable. So it's not really a
> big deal compared to other issues.
>

We have new code in 7.2 that will do MD5 encryption of passwords stored
in pg_shadow.  We add the salt to the front of the password before
passing through MD5.  You are suggesting putting the salt at the end.

I guess the issue is that if you can get the salt part found out, you
can use that to attack the password part.  Also, consider that we use
the username as the salt as stored in pg_shadow.  We can easily put the
salt in the back, but then there is the risk that a long password would
not take into account the salt.  My feeling that this is more a
theoretical concern and we may be opening ourselves up to more problems
if we make the change.

Other ideas?

--
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

pgsql-general by date:

Previous
From: "Oleg Olenin"
Date:
Subject: size of BLOB
Next
From: "Nick Fankhauser"
Date:
Subject: Re: backend stalls