Re: Encrypting pg_shadow passwords
От | Joe Conway |
---|---|
Тема | Re: Encrypting pg_shadow passwords |
Дата | |
Msg-id | 004001c0f5ab$84f62330$d7d310ac@jecw2k1 обсуждение исходный текст |
Ответ на | Encrypting pg_shadow passwords (Bruce Momjian <pgman@candle.pha.pa.us>) |
Ответы |
Re: Encrypting pg_shadow passwords
|
Список | pgsql-hackers |
> > This is unrelated to moving to MD5 encryption, which is another item on > > our list. > > It may be unrelated in theory, but in practice we should do both at > the same time to minimize the number of client-library incompatibility > issues that arise. I'd suggest that old-style crypt auth continue to > use the crypt() call forever, while the new-style should be based on > MD5 not crypt() from the get-go. > I don't know if this was discussed earlier, but for client authentication I think SHA-1 is preferred over MD5 because of weaknesses discovered in MD5. Also an HMAC using SHA-1 is preferred for authentication over just simply using a hash of the password. Ideally the server sends a random session token to the client, the client creates an HMAC (using SHA-1) from the token and their password locally, and sends that back to the server. The server then calculates the HMAC itself using the client's (server stored) password and the session token. If they match, the client is authenticated. If we want to store a SHA-1 hash instead of the plain-text password, just do SHA-1 over the plain-text password on the client side before using it as the HMAC key. The downside of storing the password as a SHA-1 hash versus symmetrically encrypting (or leaving as plain-text) it is that there's no way to recover the password from the hash if the client forgets it. Of course, the superuser can just reset it to a known value. -- Joe
В списке pgsql-hackers по дате отправления: