Greg Hudson wrote:
> On Wed, 2004-06-02 at 12:54, kfogel@collab.net wrote:
>
>>Greg Hudson <ghudson@MIT.EDU> writes:
>>
>>>I will, at some point,
>>>look into a way to make it so that the secret is a hash of the password
>>>together with the authentication domain.
If the server was storing a hash of the password and the server name
(aka authentication domain), would that mean if the client refers to
the server differently (e.g. using localhost because they're
tunnelling over SSH) then the user needs to reset their password?
Or (more likely) am I misunderstanding "authentication domain"?
>
>>How is the "secret" not a "password", then? I'm not seeing how this
>>fundamentally changes the dynamics of the situation. The server and
>>client still have to know the same secret, and the secret is not
>>transmitted in the clear over the network.
>
> It means if the user is using the same password for Subversion and for
> some other purpose, the repository administrator can't (except through
> dictionary attack) discover the password being used for the other
> purpose.
Also, it stops administrators from seeing the password accidentally.
E.g. I run a small SVN server at my company, but I'm not a proper
system administrator. Users want to use the same password for the
SVN server as for the network. However, users don't want me to know
their password, and I actively don't want to know their passwords.
With the current system I have to see all their passwords - if the
system used a password hash then users could just send me that hash.
Although theoretically I might be able to use a brute-force or
dictionary attack against their password, I'm not going to.
(Even reversible encryption/obfuscation on the password would meet
this goal).
Kind regards,
Jon
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Jun 2 21:18:43 2004