Re: [HACKERS] Solution to the pg_user passwd problem !?? (c)
От | ocie@paracel.com |
---|---|
Тема | Re: [HACKERS] Solution to the pg_user passwd problem !?? (c) |
Дата | |
Msg-id | 9802192325.AA03241@dolomite.paracel.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] Solution to the pg_user passwd problem !?? (c) (Bruce Momjian <maillist@candle.pha.pa.us>) |
Ответы |
Re: [HACKERS] Solution to the pg_user passwd problem !?? (c)
|
Список | pgsql-hackers |
Bruce Momjian wrote: > > > > > On Thu, 19 Feb 1998, Bruce Momjian wrote: > > > > > > > > > > > > > > Have we considering using the unix crypt function for passwords? That > > > > way it wouldn't matter (as much) if people saw the password, and would > > > > still be (somewhat less) secure. > > > > > > > > On Thu, 19 February 1998, at 15:55:07, Jan Wieck wrote: > > > > > > I don't know what the problem with using crypt was. It may be because > > > he passes a random salt to the user, and the user makes the password > > > packet with the given salt and returns it to the backend. If we use > > > crypt, we have to send a plaintext password over the network, don't we? > > > > But, aren't we doing that now? > > Yes, we are using crypt. We are picking a random salt, using crypt to > encrypt the cleartext password, then sending the salt to the frontend, > and asking them to supply a password crypted with our requested salt. > > Anyway to do this while storing encrypted passwords? Standard salt is two characters, so an adversary might be able to watch and record which salts produced which replies. Even with a single login, a brute force attack might still be able to get the user's password. A stronger challenge-response system might be more secure. It should be possible for the server to authenticate a user without having to store the user's password. Then again, this is all starting to sound like Kerberos, so if Postgres had Kerberos authentication (which I think it does), then this could be used for the ultra-high security authentication system. Ocie Mitchell
В списке pgsql-hackers по дате отправления: