Chris AtLee wrote:
>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.
>
>
Er, pray tell, how is this different from storing cleartext passwords on
the server, as we're doing now? If client and server both start with the
same hash, it's as if the hash were the cleartext password.
>Sending a simple hash of the password over the network is just as
>insecure as sending the password in the clear.
>
>
But we use CRAM-MD5, which is exactly what you describe.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Nov 15 17:37:45 2004