Re: Encrypting pg_shadow passwords
От | Jim Mercer |
---|---|
Тема | Re: Encrypting pg_shadow passwords |
Дата | |
Msg-id | 20010625234226.I1599@reptiles.org обсуждение исходный текст |
Ответ на | Re: Encrypting pg_shadow passwords (Bruce Momjian <pgman@candle.pha.pa.us>) |
Ответы |
Re: Encrypting pg_shadow passwords
Re: Encrypting pg_shadow passwords |
Список | pgsql-hackers |
On Mon, Jun 25, 2001 at 11:27:42PM -0400, Bruce Momjian wrote: > I am replying to the original message because it has all the relevant > information. The problem with 'password' authentication is that the > password goes across the wire in plaintext. Now, if we start to ship > encrypted passwords across the wire, but use the same salt for every > authentication request, we are really no more secure than if we sent it > in the clear. > > If a user specifies 'crypt' in pg_hba.conf, they should be assured that > the password is safe in case someone snoops it. Encrypting pg_shadow > and comparing that with the same salt every time is not secure from > snooping so we don't allow it. > > Am I missing something? i don't disagree that sending plaintext across the wire, if possible, it should be avoided. however, i look at it this way. many _existing_ implementations send plaintext across the wire, telnet, ftp, .htaccess, imap and pop (non-ssl). i would much rather risk a single plain-text password being snooped on the wire, rather than having an entire database of plain-text passwords for someone to scoop. many people re-use passwords for multiple purposes, thus reducing the bio-core required to keep track of a bazillion passwords. in my opinion, storing plain-text passwords in any media is just plain wrong, and a far greater security risk than having a password sniffed. in my applications, i have SSL covering the client->app (browser->PHP code), so the sniffing would need to be on the wire from the app-server -> database server, which in many cases is the same machine. my mods don't alter the operation of the server in any respect. they do, however, allow people the choice of using a traditional telnetd/binlogin authentication scheme without resorting to external password files. -- [ Jim Mercer jim@reptiles.org +1 416 410-5633 ] [ Now with more and longer words for your reading enjoyment. ]
В списке pgsql-hackers по дате отправления: