Re: Encoding passwords

Поиск
Список
Период
Сортировка
От Bruce Momjian
Тема Re: Encoding passwords
Дата
Msg-id 200109271858.f8RIwbA01970@candle.pha.pa.us
обсуждение исходный текст
Ответ на Re: Encoding passwords  (Lincoln Yeoh <lyeoh@pop.jaring.my>)
Ответы Re: Encoding passwords
Re: Encoding passwords
Список 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 по дате отправления:

Предыдущее
От: "Oleg Olenin"
Дата:
Сообщение: size of BLOB
Следующее
От: "Nick Fankhauser"
Дата:
Сообщение: Re: backend stalls