> -----Original Message-----
> From: Hadmut Danisch [mailto:hadmut_at_danisch.de]
> Sent: zondag 6 april 2008 14:39
> To: dev_at_subversion.tigris.org
> Subject: subversion reveals passwords
>
> Hi,
Hi Hadmut,
>
> a known but still insecure fact is that subversion store passwords
> for repository accounts in plaintext in local files (when used with
> linux).
>
> I've been discussing that fact in the users mailing list. A common
> argument
> is that the user is expected to know about this issue and that it is
> possible
> to turn off that storage of passwords in the config files.
The current design was chosen to make it possible to only transfer a
not-decipherable hash over the network.
To make it possible to transfer a not-decipherable hash of the password over
the network a local copy of the password must be available, either typed by
the user or from some storage backend.
The only other option for password authorization is storing a hash locally
and transferring that exact same hash. But that would make the hash (for the
authentication) the password itself.
Sending the password plain text to the server doesn't seem the right thing
to do. (If I can't trust the local machine I certainly can't trust the
network.)
> Storing passwords in local files can be harmful if, e.g. the repository
> is protected with
> LDAP and the same passwords for common company authentication. In
> reality,
> subversion stores these passwords onto hard discs and thus compromises
> company
> security.
If the subversion binary is able to decipher a password from disk using
reversible encryption; any other software package could do the same by just
copying our code.
The only thing that could help subversion is the OS. (On Windows and Mac
pc's the os encrypts the passwords for us; patches for other operating
systems are welcome ;-)
These answers should (in other words) be available in the mailing archive...
probably quite a few times, as it is a quite commonly asked question
However there are other ways to authenticate -like certificates- which don't
have this problem and are secure even if you don't trust the file store. But
that would require another server setup.
http:// / https:// : Subversion 1.3+ allows using client certificates and
SSPI connections (Windows only) over http and https. This does not even
require typing the password in subversion.
(We use this method extensively at The Competence Group)
(There should be a few new options in the newer neon versions used by 1.5
but I haven't really looked at them)
svn:// : Subversion 1.5+ allows using all sasl authentication types to
authenticate to svn:// servers. (NTLM, SSPI, Kerberos, etc) which all have
their own forms of authentication without storing passwords locally. (It
also has other options to store it)
(I'm looking at using this option to speed up common operations)
This should work for all common operating systems. Especially the Kerberos
authorization should be a viable option in corporate environments using a
single logon environment over several systems.
svn+ssh:// : For svn+ssh:// all authorization is handled by the ssh
tunneling client. This allows a number of authentication types, including
client certificates and external authorization agents.
> The need to modify configuration files proved to not be reliable in
> reality.
Changing the autorization to one of the above methods lets the server
administrator choose what to store.
But in my personal opinion: if you don't trust the user/the os in keeping
their settings safe, you (as sysadmin) have already lost.
My windows account I use for development does not have any more rights than
absolutely necessary (less rights than most of my colleagues). For my
sysadmin tasks I have a bunch of other accounts of which I will never use
the password in any client application.
(On Windows subversion allows specifying options in the registry; which can
be rolled out via a group policy in a corporate environment)
> I therefore propose to modify the way subversion treats passwords:
>
> - Drop that option from the config file. It should not be possible
> anymore to drive subversion
> into a mode where it writes passwords to disk without explicit user
> confirmation.
Even if we would like to (which I don't expect as the current design was
discussed thoroughly in the initial design stage of subversion), we could do
this only for subversion 2.0.
We would break every rule about keeping subversion compatible over 1.x by
applying such a change.
> - Allow a new command line option for those cases, where the users
> wants
> the password
> to be stored. Require that option to be explicitely given for every
> single password to be
> stored. Issue a warning message.
There are many more subversion clients than just the commandline. We can't
change the public c api for just for a few command line cases.
Bert Huijben
> regards
> Hadmut
---------------------------------------------------------------------
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-06 20:44:35 CEST