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. |

| Subject: | Re: [HACKERS] Postgres: pg_hba.conf, md5, pg_shadow, encrypted |
|---|---|
| Date: | Sat, 23 Apr 2005 09:02:37 -0400 |
* Antoine Martin (antoine@nagafix.co.uk) wrote:
Basically, multiple input data that have the same output hash, which is of no use when what you are trying to find is the input. Finding collisions quicker for a known input is one thing, but that is not going to reduce the search space, not even your storage space (it is unlikely that the colliding results would all be valid input).
Erm, you aren't necessairly trying to find the input... It may be the case that you're trying to find what you need to authenticate to this server, or any other PostgreSQL server where the same userid & input are used. In that case you just need something that hashes to the same thing. Using a random salt would mean that it's different per server so breaking it on one doesn't help you against another server unless you happened to find the actual original input.
Is adding the non-guessable salt that hard anyway?
It is if you want to continue to support the 'md5' method in pg_hba.conf
because the wireline protocol will probably need to change. A less
intrusive alternative would be to add an 'with encrypted password 'xyz'
with random salt' or some such which would only be supported with the
'password' method in pg_hba.conf.
One problem with this is that you then can't just switch from password
to md5 or back again. Perhaps that's ok though? Comments?
Stephen
signature.asc
Description: Digital signature
| Previous by Date: | E-Cart v1.1 Remote Command Execution, Nicolas Montoza |
|---|---|
| Next by Date: | [Full-disclosure] Re: -==phpBB 2.0.14 Multiple Vulnerabilities==-, Paul Laudanski |
| Previous by Thread: | Re: [HACKERS] Postgres: pg_hba.conf, md5, pg_shadow, encrypted passwords, Antoine Martin |
| Next by Thread: | Re: [HACKERS] Postgres: pg_hba.conf, md5, pg_shadow, encrypted, Antoine Martin |
| Indexes: | [Date] [Thread] [Top] [All Lists] |