On Fri, 2004-12-11 at 19:07 -0600, kfogel@collab.net wrote:
> Branko Čibej <brane@xbc.nu> writes:
> > Oof. I just read the CRAM-MD5 RFC, and it doesn't require you to store
> > cleartext on the server. We could store hashed passwd representations
> > on the server without changing client code. But if someone lifted
> > those hashes off of the server, they'd be able to modify the client to
> > authenticate with the server anyway.
>
> Congratulations, you've just come full circle... as does everyone who
> thinks about CRAM-MD5. The hash becomes the plaintext :-).
>
> Basically, if we're not doing public-key cryptography, then we have
> two choices:
>
> Client and server store password hashed, but it goes over the wire
> in the clear.
>
> -or-
>
> Client and server store password in the clear, but it goes over the
> wire hashed.
>
> We decided to protect the wire, which I think is a good choice.
Third choice:
Client and server store salted password hashed. Server provides a
random challenge string along with request for authentication. Both
client and server apply the HMAC algorithm (RFC 2104) which results in a
new hash. The client sends this hash to the server, if it matches what
the server generated, then the user is authenticated. This doesn't
protect against the hash being stolen from the server and a hacked
client being used, but it does protect against somebody sniffing the
network traffic. Salting the passwords before hashing them protects
against the original password being derived from the hash.
Sending a simple hash of the password over the network is just as
insecure as sending the password in the clear.
To really make the server secure I think you'd either need to use
public/private key encryption, or protect all the stored hashes on the
server with a password. When the server starts up, the administrator
must enter in a password to decrypt the hashes - which are then stored
in protected / unswappable memory...Which is starting to sound an awful
lot like ssh-based authentication :)
Cheers,
Chris
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Nov 15 16:51:03 2004