On Fri, Jun 15, 2001 at 07:57:37AM -0700, Joe Conway wrote:
> > > 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.
Well said. (I don't recall what HMAC stands for; maybe others don't also.)
A diagram of the above, if you'll forgive the ASCII art, is:
password random challenge (from server) | | (SHA)
| | |PW hash (stored in server) | |
| +--------------> + <------------+ | (SHA) | (compare)
> 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.
I see no value in supporting password recovery, and good reasons not to
support it. Using MD5 or SHA implies we should talk about "password
hashing" rather than "password encryption".
Nathan Myers
ncm@zembu.com
