* Tom Lane (tgl (at) sss.pgh.pa (dot) us [email concealed]) wrote:
> "Jim C. Nasby" <decibel (at) decibel (dot) org [email concealed]> writes:
> > Simply put, MD5 is no longer strong enough for protecting secrets. It's
> > just too easy to brute-force. SHA1 is ok for now, but it's days are
> > numbered as well. I think it would be good to alter SHA1 (or something
> > stronger) as an alternative to MD5, and I see no reason not to use a
> > random salt instead of username.
>
> Well, I have no particular problem with offering SHA1 as an alternative
> hash method for those who find MD5 too weak ... but I still question the
SHA2 would also be nice.
> value of putting any random salt in the table. AFAICS you would have to
> send that salt as part of the initial password challenge, which means
> any potential attacker could find it out even before trying to
> compromise pg_shadow; so Stephen's argument that there is a useful
> improvement in protection against precomputation of password hashes
> still falls down.
Only if you're using 'md5' in pg_hba.conf. In that case, yes, you would
have to send the salt as part of the password challenge. Personally, I
would discourage use of 'md5' in pg_hba.conf because of this and because
it changes the authentication token from the password to the hash which
is what is directly stored in the database.
> BTW, one could also ask exactly what threat model Stephen is concerned
> about. ISTM anyone who can obtain the contents of pg_shadow has
> *already* broken your database security.
Just because they have access to pg_shadow does not necessairly mean
they have access to the database files directly or are able to write to
anything (such as to destroy data). It's possible they pulled
pg_shadow off a backup tape and are bent on destroying all the data in
your live database, and not in just reading it, or if your data is very
time sensitive then they want a more recent version for its value, etc.
There are other possibilities but my concern centers around a partial
system compromise where pg_shadow is obtained by the attacker, yes.
> "Jim C. Nasby" <decibel (at) decibel (dot) org [email concealed]> writes:
> > Simply put, MD5 is no longer strong enough for protecting secrets. It's
> > just too easy to brute-force. SHA1 is ok for now, but it's days are
> > numbered as well. I think it would be good to alter SHA1 (or something
> > stronger) as an alternative to MD5, and I see no reason not to use a
> > random salt instead of username.
>
> Well, I have no particular problem with offering SHA1 as an alternative
> hash method for those who find MD5 too weak ... but I still question the
SHA2 would also be nice.
> value of putting any random salt in the table. AFAICS you would have to
> send that salt as part of the initial password challenge, which means
> any potential attacker could find it out even before trying to
> compromise pg_shadow; so Stephen's argument that there is a useful
> improvement in protection against precomputation of password hashes
> still falls down.
Only if you're using 'md5' in pg_hba.conf. In that case, yes, you would
have to send the salt as part of the password challenge. Personally, I
would discourage use of 'md5' in pg_hba.conf because of this and because
it changes the authentication token from the password to the hash which
is what is directly stored in the database.
> BTW, one could also ask exactly what threat model Stephen is concerned
> about. ISTM anyone who can obtain the contents of pg_shadow has
> *already* broken your database security.
Just because they have access to pg_shadow does not necessairly mean
they have access to the database files directly or are able to write to
anything (such as to destroy data). It's possible they pulled
pg_shadow off a backup tape and are bent on destroying all the data in
your live database, and not in just reading it, or if your data is very
time sensitive then they want a more recent version for its value, etc.
There are other possibilities but my concern centers around a partial
system compromise where pg_shadow is obtained by the attacker, yes.
Thanks,
Stephen
[ reply ]