Re: You're on SecurityFocus.com for the cleartext passwords.
От | Tom Lane |
---|---|
Тема | Re: You're on SecurityFocus.com for the cleartext passwords. |
Дата | |
Msg-id | 9651.957596955@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: You're on SecurityFocus.com for the cleartext passwords. (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: You're on SecurityFocus.com for the cleartext passwords.
|
Список | pgsql-hackers |
I wrote: > The main potential hazard I see is portability. Is crypt(3) available > on *all* the platforms Postgres runs on? Waitasec, what am I saying? We already *do* have crypt password support, at least on those platforms where crypt(3) is available. As near as I can tell, the crypt option transmits an encrypted password across the wire (good), but the comparison at the server end is done by taking the cleartext password stored in pg_shadow, crypt()ing it on the fly, and comparing that to what was sent by the client. This does have the advantage that the same pg_shadow entry will support both cleartext-password and crypted-password connections, but we could get that another way. Assuming that the server has crypt(), the password could be stored always encrypted instead of always not. Cleartext-password connections would be handled just by crypting the received password before comparing. (Before you ask, no I don't think we should remove the option of cleartext-password connections. What of clients running on platforms with neither crypt() nor anything better like Kerberos? Should they be forced to drop down to no security at all? I think not.) This'd take some rejiggering in (at least) CREATE USER and ALTER USER, but it seems doable. I withdraw the complaint about portability... regards, tom lane
В списке pgsql-hackers по дате отправления: