Ryan Schmidt wrote:
>
>> The really bad thing about this is that it not just compromises
>> subversion, but can compromise the security of the whole LAN.
>>
>> Absolutely bad design.
>
> The Subversion client needs to provide the plain text password to the
> Apache server during authentication. Suggest a way for this to be
> accomplished without storing the plain text password on the client's disk.
Have the server generate a unique cookie that it sends back to the
client to save for subsequent authentication that will only work for
subversion access - and perhaps only for a configurable amount of time.
> Encrypting the password on the client's disk is not a solution unless
> the Subversion client can also decrypt the password again so it can be
> provided to Apache in plain text. And if the Subversion client, whose
> source is public, can do this, then any other software can do this too
> so it is no more secure than storing the plain text password on disk.
The real problem is that most people won't want to create unique logins
and maintain separate passwords for subversion access, so the password
that svn stores insecurely will likely permit access to many other
things on the network. It's not great if someone can impersonate you
with a subversion client, but at least there are tools to track and undo
the changes they might make. Other things that are likely to be
accessible with that same password won't have the same mechanism to
protect their earlier revisions or log the changes.
--
Les Mikesell
lesmikesell_at_gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-03-20 16:08:56 CET