| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | "Meredith L(dot) Patterson" <mlp(at)osogato(dot)com> |
| Cc: | Magnus Hagander <magnus(at)hagander(dot)net>, Jim Michaels <jmichae3(at)yahoo(dot)com>, pgsql-bugs(at)postgresql(dot)org |
| Subject: | Re: BUG #4876: author of MD5 says it's seriously broken - hash collision resistance problems |
| Date: | 2009-06-25 16:03:30 |
| Message-ID: | 22999.1245945810@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
"Meredith L. Patterson" <mlp(at)osogato(dot)com> writes:
> Magnus Hagander wrote:
>> We might want to consider using a safer hash for the password storage at
>> some point, but from what I gather it's not really urgent for *that* use.
>>
> It would be a lot more urgent if we weren't salting, but IIRC we are.
I don't really see that there's any issue here at all. The point of the
hashing is to prevent a superuser (non-superusers can't look at the
stored hashvalue anyway) from recovering the user's actual password.
This is not for the purpose of protecting the database itself ---
superusers already have all the keys to the kingdom in that respect.
It's only meant to protect a user who's unwisely used the same password
for multiple services from having a database breakin mean that his other
services are compromised as well.
Being able to make up strings that hash to the same thing doesn't create
a vulnerability of this sort, AFAICS. You've found something that the
database would accept as being a valid password, but that doesn't mean
that it will work for other services.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Simon Riggs | 2009-06-25 16:11:36 | Re: BUG #4879: bgwriter fails to fsync the file in recovery mode |
| Previous Message | Simon Riggs | 2009-06-25 15:59:32 | Re: BUG #4879: bgwriter fails to fsync the file in recovery mode |