> -----Original Message-----
> From: news [mailto:news_at_ger.gmane.org] On Behalf Of Duncan Booth
> Sent: maandag 7 april 2008 13:13
> To: dev_at_subversion.tigris.org
> Subject: Re: subversion reveals passwords
>
> Karl Fogel <kfogel_at_red-bean.com> wrote:
>
> > Duncan Booth <duncan.booth_at_suttoncourtenay.org.uk> writes:
> >> That isn't the only option. For example you could store a hash
> >> locally and transfer a hash of the hash. That way you still aren't
> >> sending the stored value across the network (and you can use a
> >> challenge response system to ensure the value which is sent is
> >> different every time) but if the stored password is leaked the
> >> original plaintext password (which may be being used for other
> >> systems too) isn't compromised.
> >
> > But then the stored hash becomes, effectively, the plaintext
> password,
> > and we are still storing it locally.
> >
> > (Work it out, you'll see what I mean.)
>
> Phil Marek understood my point: access to the Subversion repository is
> neither more nor less secure than before, but compromising the hashed
> password used by Subversion would no longer compromise other systems
> where
> the same plaintext password was being used.
But this would be at the price of not being able to verify the password
against an existing dictionary (service) at the server... (e.g. LDAP)
As that dictionary would have to use the hashes too...
(Which would make the hash effectively the password... which brings us back
to...)
The only method to really resolve these issues is not to use a pre shared
key as the only method of authentication at all.
E.g. Use a challenge response or cookie system like SSPI, Kerberos, etc.
etc.
Which we all support in subversion... but which are not pre shared key based
systems..
Bert Huijben
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-04-07 13:31:37 CEST