| From: | Tycho Fruru <tycho(at)fruru(dot)com> |
|---|---|
| To: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
| Cc: | Scott Lamb <slamb(at)slamb(dot)org>, pgsql-general(at)postgresql(dot)org |
| Subject: | Re: Postgresql -- initial impressions and comments |
| Date: | 2002-12-03 23:34:30 |
| Message-ID: | 1038958471.1254.6.camel@bozo.fruru.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
On Tue, 2002-12-03 at 23:50, Bruce Momjian wrote:
> Scott Lamb wrote:
> > That's disconcerting to me because I think it defeats the point of
> > sending MD5 signatures on the wire - avoiding replay attacks. If it's
> > stored in MD5 format on the server, it can't request it with a different
> > salt every time (how would it compare them?), so you can just replay the
> > MD5 transmission.
> >
> > The other way, though, a compromise of the database would mean a
> > compromise of all the passwords.
> >
> > So it definitely would be helpful to have an answer to your question in
> > with the description of the authentication types, so you could choose
> > intelligently based on what you consider to be more likely risks.
>
> 7.3 stores encrypted MD5 passowords in database (7.2 it is optional).
> We send random salt to client and client double-MD5 encrypts, so
> playback will not work --- best of both worlds.
So, if I understand it correctly :
- on the wire : no cleartext passwords, only doubly hashed + salted
passwords -> no replay possible (watch out for session hijacking though)
nor password sniffing
- in the database : no cleartext passwords are stored, but access to the
md5 hashed passwords is sufficient to get access to the database -
without really knowing the user's password - by using a modified client.
Is this correct ?
cheers
Tycho
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bruce Momjian | 2002-12-03 23:37:07 | Re: Postgresql -- initial impressions and comments |
| Previous Message | Peter Eisentraut | 2002-12-03 23:33:44 | Re: [GENERAL] PostgreSQL Global Development Group Announces |