> > 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
