Ethical Hacking

Learn to find vulnerabilities before the bad guys do! Gain real world hands on hacking experience in our state of the art hacking lab. Course designed and taught by expert instructors with years of penetration testing experience. 12 student maximum in every class. Certification attempt included in every package.
Computer Forensics Training at InfoSec Institute

Gain the in-demand skills of a certified computer examiner, learn to recover trace data left behind by fraud, theft, and cybercrime perpetrators. Discover the source of computer crime and abuse at your organization so that it never happens again. All of our class sizes are guaranteed to be 12 students or less to facilitate one-on-one interaction with one of our expert instructors.




Network Security Bugtraq
[Top] [All Lists]

Re: [HACKERS] Postgres: pg_hba.conf, md5, pg_shadow, encrypted passwords

Subject: Re: [HACKERS] Postgres: pg_hba.conf, md5, pg_shadow, encrypted passwords
Date: Wed, 20 Apr 2005 22:27:01 -0400
* Tom Lane (tgl@sss.pgh.pa.us) wrote:
"Jim C. Nasby" <decibel@decibel.org> 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

Attachment: signature.asc
Description: Digital signature

<Prev in Thread] Current Thread [Next in Thread>