Re: You're on SecurityFocus.com for the cleartext passwords.
От | Bruce Momjian |
---|---|
Тема | Re: You're on SecurityFocus.com for the cleartext passwords. |
Дата | |
Msg-id | 200005061517.LAA10084@candle.pha.pa.us обсуждение исходный текст |
Ответ на | Re: You're on SecurityFocus.com for the cleartext passwords. (Vince Vielhaber <vev@michvhf.com>) |
Ответы |
Re: You're on SecurityFocus.com for the cleartext passwords.
Re: You're on SecurityFocus.com for the cleartext passwords. Re: You're on SecurityFocus.com for the cleartext passwords. |
Список | pgsql-hackers |
> > The goal here was to make wire sniffing unproductive, and because the > > server supplied the salt to be used by the client, you can't just > > re-use a sniffed password you saw on the wire. > > > > At least this is my recollection of the problem. > > > > > > We can do it with MD5. Sverre has offered up a java version of it > that he wrote, I can convert it to C and make sure it at least runs > on FreeBSD, IRIX, DOS/Windows, and HPUX 8-10. If it runs in unix then > it should also run in OS/2. If we roll our own we should be safe. I > can even include a simple test to make sure it works for all platforms > we support. Yes, I seem to remember that was the issue. If we only did crypting on the server, and allowed passwords to come cleartext from clients, then we only needed crypting on the server. If we crypt in a one-way fashion on the client before coming to the server using a random salt, we have to do the other part of the crypting on the client too. In other words, it is the one-way nature of the password crypt we used on the client that caused us to need the _exact_ same input string to go into that crypt on the client and server, so we would need the same crypt process in both places. Now, let me ask another, better question: Right now the password receives a random salt from the server, it uses that salt to crypt the password, then send that back for comparison with the clear-text password we store in the system. What if we:store the password in pg_shadow like a unix-style password with saltpass the random salt and the salt from pg_shadowto the clientclient crypts the password twice through the routine: once using the pg_shadow salt another timeusing the random salt and passes that back to the server. The server can use the pg_shadow copy of the password, use the random salt make a new version, and compare the result. This has the huge advantage of not requiring any new crypting methods on the client. It only requires the crypt to happen twice using two different salts. Sounds like a winner. Comments? -- Bruce Momjian | http://www.op.net/~candle pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
В списке pgsql-hackers по дате отправления: