Re: Salt in encrypted password in pg_shadow

Поиск
Список
Период
Сортировка
От David Garamond
Тема Re: Salt in encrypted password in pg_shadow
Дата
Msg-id 413DFB69.8080302@zara.6.isreserved.com
обсуждение исходный текст
Ответ на Re: Salt in encrypted password in pg_shadow  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Salt in encrypted password in pg_shadow
Список pgsql-general
Tom Lane wrote:
> I think David is suggesting that the hypothetical attacker could gain
> economies of scale in multiple attacks (ie, if he'd been able to steal
> the contents of multiple installations' pg_shadow, he'd only need to
> generate his long list of precalculated hashes once).  I think this is
> too far-fetched to justify an authentication protocol change though.
>
> Also, MD5 hashing is fast enough that I'm not sure the above is really
> significantly cheaper than a straight brute-force attack, ie, you just
> take your list of possible passwords and compute the hashes on the fly.
> The hashes are going to be much longer than the average real-world
> password, so reading in a list of hashes is going to take several times
> as much I/O as reading the passwords --- seems to me that it'd be
> cheaper just to re-hash each password.

Many people use short and easy-to-guess passwords (remember we're not
talking about the superuser only here), so the dictionary attack can be
more effective than people think. And considering many people use the
same password for several things, Postgres could become one of the easy
sources to get/guess people's plaintext passwords from hacked machines.

At least Apache and Unix have been random-salting passwords for a while now.

However, I realize this will break the current MD5 hash, probably too
painful to do at the moment. Perhaps for the future, non-MD5 hash...

--
dave

В списке pgsql-general по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: ERROR: canceling query due to user request
Следующее
От: David Garamond
Дата:
Сообщение: Restoring dump of multiuser databases