You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Hadmut Danisch <ha...@danisch.de> on 2008/03/19 22:58:39 UTC
Security flaw: subversion stores passwords by default
Hi,
I just installed a subversion repository together with webdav and an
apache server, protected
by password authentication over LDAP and HTTPS.
Accessing this repository over HTTPS worked perfectly except for a
severe security
problem:
Unless turned off in the users (or common) configuration file,
subversion stores the password
in plain textfiles. Since the web access password is the same as the
common account password
used for several services, unexperienced users compromise their own
passwords without even
realizing it.
Although not a bug in the common sense, this is a severe security flaw
by design.
I would strongly recommend to modify this behavior and to never ever let
subversion store
any password by itself. If the password should be stored locally, then
the user should do
it himself or at least give an option to do so.
And, btw., would be nice to support the https://user@server/... syntax
or a way to take the
user from environment or configuration.
regards
Hadmut
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Security flaw: subversion stores passwords by default
Posted by Les Mikesell <le...@gmail.com>.
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@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Security flaw: subversion stores passwords by default
Posted by Les Mikesell <le...@gmail.com>.
Daniel Danger Bentley wrote:
>
>>> 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.
>> In the high security area where I am currently maintaining a protected
>> SVN respository, the users are required to reenter the password any time.
>>
>> Even beyond that requirement, there's another problem:
>>
>> Some files need to be checked out from SVN with root permissions, but
>> with user/password of the person who is root at that very moment. While
>> several people share access to the root accounts, nobody should be able
>> to check in changes under the name of a different person (or be able to
>> read the password from the file system).
>>
>
> I don't know much about subversion (just joined), but this caught my eye:
> Why are multiple people sharing an account? If you don't trust your users,
> then why do you trust them to share an account?
People with root permissions aren't users, they are machine
administrators and you have to balance the ability to keep things
running against the number of people who have complete access. Aside
from the issue of sharing user accounts or working directories being a
bad idea, there will always be some number of machine administrators
that can read any file, and copies of the files are likely to end up in
backups that some other set of people can access. You should, of
course, trust people you put in these positions, but that doesn't mean
you should hand them plain-text copies of passwords that are very likely
to be used for other purposes as well. Most other programs recognize
this and make at least some effort to obscure the passwords so a casual
glance at the file won't expose them. I'd look at it like locking a
door with a glass panel. It is still worth doing even if you know it
won't stop a determined thief.
--
Les Mikesell
lesmikesell@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: Re: Security flaw: subversion stores passwords by default
Posted by "Gleason, Todd" <tg...@impac.com>.
In Windows you can set up files or directories to be encrypted, which
would mean that only the specific user could read them based on the
user's login password. I assume that if they were copied to tapes, they
would stay encrypted.
I'm not sure how Linux compares in this regard, but if it has such an
option, that would be my first suggestion.
If you wanted to keep the password off the drive entirely, I'm not sure
what you'd do, since from what I understand, you'd have to enter your
password for every Subversion command. If there's a good way to keep a
sort of "session state" (possibly through a daemon and some IPC) that
holds your password only until you logout, that might be another
solution, but it sounds like that would have to be written into the
Subversion client libraries and it might be platform-specific. I'm not
sure if you could keep the passwords out of the swap file either, though
you could at least obfuscate them in memory.
I'm no security expert though. Perhaps there are well-established ways
of solving this problem, because I doubt it is specific to Subversion.
-----Original Message-----
From: Hadmut Danisch [mailto:hadmut@danisch.de]
Sent: Friday, March 21, 2008 11:31 AM
To: Daniel Danger Bentley
Cc: Ryan Schmidt; Blair Zajac; users@subversion.tigris.org
Subject: Re: Security flaw: subversion stores passwords by default
Obviously, they should not be checked in or out as root, but as the
admin who is currently doing the job. Therefore, every admin has to
check in and out with his personal login name and passwords. Works
exactly as expected. Being root while accessing the SVN as John or Jane
Doe.
But if the passwords are stored unintentionally under /root, the next
admin could accidently use or read that password.
Another problem: If the admins or regular users write their own
passwords onto the harddisk, they would be written onto backup tapes as
well. Whoever gets access to one of these backup tapes would get the
passwords for free.
Same if an attacker managed to enter a machine: Find the passwords and
break into every other machine (although I agree that he could achieve
the same with modifying the login or svn binaries to store the passwords
somewhere else, but there's no need to make it that easy.)
Reality showed that even if you are fully aware of the problem, there's
always a machine where the config file is as it was delivered by the
linux package.
But this all boils down to a simple rule at the end of the day:
It is a really bad idea to write passwords in plaintext and without
protection into files.
And the discussion so far about trust, passwords on the wire, and so on
showed that the design is based on odd assumptions that do not hold in
common.
regards
Hadmut
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Security flaw: subversion stores passwords by default
Posted by Hadmut Danisch <ha...@danisch.de>.
Daniel Danger Bentley wrote:
>
>
> Some files need to be checked out from SVN with root permissions, but
> with user/password of the person who is root at that very moment.
> While
> several people share access to the root accounts, nobody should be
> able
> to check in changes under the name of a different person (or be
> able to
> read the password from the file system).
>
>
> I don't know much about subversion (just joined), but this caught my
> eye: Why are multiple people sharing an account? If you don't trust
> your users, then why do you trust them to share an account?
Pretty good point, I'm glad to see someone thinking about and verifying
my arguments.
Let me explain this with an example:
My concerns are about computing centers with higher security
requirements than normal, partly required by contracts, partly required
by law. So this is not just about "trusting users", this is about
fulfilling external security requirements.
One of these requirements is that certain files are to be protected and
must be accessible to identified and authenticated individuals only,
that's why SVN access is used over HTTPS and with password protection.
Another requirement is that passwords must not be stored in plaintext.
Usually, people do not share accounts and have their own one. But there
are some special cases where this can't be avoided.
E.g. there are server machines that are maintained by a team of system
administrators. Obviously, every one of them must have access to the
root account to install software etc. So when working as administrators,
each of them could become root.
The configuration details (i.e. several files under /etc) must be kept
in a repository with version control, history, change management and
access logging. Subversion perfectly does that job. So several files
under /etc are under subversion control.
Obviously, they should not be checked in or out as root, but as the
admin who is currently doing the job. Therefore, every admin has to
check in and out with his personal login name and passwords. Works
exactly as expected. Being root while accessing the SVN as John or Jane
Doe.
But if the passwords are stored unintentionally under /root, the next
admin could accidently use or read that password.
Another problem: If the admins or regular users write their own
passwords onto the harddisk, they would be written onto backup tapes as
well. Whoever gets access to one of these backup tapes would get the
passwords for free.
Same if an attacker managed to enter a machine: Find the passwords and
break into every other machine (although I agree that he could achieve
the same with modifying the login or svn binaries to store the passwords
somewhere else, but there's no need to make it that easy.)
Reality showed that even if you are fully aware of the problem, there's
always a machine where the config file is as it was delivered by the
linux package.
But this all boils down to a simple rule at the end of the day:
It is a really bad idea to write passwords in plaintext and without
protection into files.
And the discussion so far about trust, passwords on the wire, and so on
showed that the design is based on odd assumptions that do not hold in
common.
regards
Hadmut
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Security flaw: subversion stores passwords by default
Posted by Daniel Danger Bentley <dt...@gmail.com>.
On Thu, Mar 20, 2008 at 5:36 PM, Hadmut Danisch <ha...@danisch.de> wrote:
> Hi,
>
> Ryan Schmidt wrote:
> >
> > 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.
> In the high security area where I am currently maintaining a protected
> SVN respository, the users are required to reenter the password any time.
>
> Even beyond that requirement, there's another problem:
>
> Some files need to be checked out from SVN with root permissions, but
> with user/password of the person who is root at that very moment. While
> several people share access to the root accounts, nobody should be able
> to check in changes under the name of a different person (or be able to
> read the password from the file system).
>
I don't know much about subversion (just joined), but this caught my eye:
Why are multiple people sharing an account? If you don't trust your users,
then why do you trust them to share an account?
-Dan
>
> If someone really wants to store the password in a local file either for
> good reasons or for not taking care, let him do. But under any
> circumstances avoid storing the password accidently.
>
>
> >
> > 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.
> Mostly correct. But this does not imply that you have to store the
> password if the user does not want this.
>
> (There are better ways to store it locally, e.g. protect it with a
> master password, like firefox, ssh-agent or the gnome/kde wallets do.
>
> A more complicated method for the future might be to use plugins, which
> can access the gnome/kde wallets.)
>
>
> regards
> Hadmut
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
>
--
'Ladislav Sticha, the tall spokesman for Czech Television, told me that the
show's audience was "miniature" — presumably he meant small in number.' -
New York Times, January 24, 2008
Re: Security flaw: subversion stores passwords by default
Posted by Hadmut Danisch <ha...@danisch.de>.
Hi,
Ryan Schmidt wrote:
>
> 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.
In the high security area where I am currently maintaining a protected
SVN respository, the users are required to reenter the password any time.
Even beyond that requirement, there's another problem:
Some files need to be checked out from SVN with root permissions, but
with user/password of the person who is root at that very moment. While
several people share access to the root accounts, nobody should be able
to check in changes under the name of a different person (or be able to
read the password from the file system).
If someone really wants to store the password in a local file either for
good reasons or for not taking care, let him do. But under any
circumstances avoid storing the password accidently.
>
> 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.
Mostly correct. But this does not imply that you have to store the
password if the user does not want this.
(There are better ways to store it locally, e.g. protect it with a
master password, like firefox, ssh-agent or the gnome/kde wallets do.
A more complicated method for the future might be to use plugins, which
can access the gnome/kde wallets.)
regards
Hadmut
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Security flaw: subversion stores passwords by default
Posted by Ryan Schmidt <su...@ryandesign.com>.
On Mar 19, 2008, at 19:02, Hadmut Danisch wrote:
> Blair Zajac schrieb:
>
>> See
>>
>> http://subversion.tigris.org/faq.html#plaintext-passwords
>> http://svnbook.red-bean.com/nightly/en/
>> svn.serverconfig.netmodel.html#svn.serverconfig.netmodel.credcache
>
> Thanks, but I am pretty much aware of this.
>
> This does not make it any less insecure. On the contrary: This is
> insecure by design. If many people have
> complained before, and the authors still intentionally keep such
> flaws, what is their idea of security?
>
> Just read that:
>
> " Trust your OS to protect data on disk."
>
> That's nonsense. What do they believe why passwords stored by the
> operating system are usually hashed and salted?
>
> What makes them believe that exactly that OS will be in place all
> time?
>
> That sort of approach is really silly. If you can't do it in a
> secure way, than don't do it at all (at least not without explicit
> user consent).
>
>
> 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.
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.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Security flaw: subversion stores passwords by default
Posted by Vincent Lefevre <vi...@vinc17.org>.
On 2008-03-19 23:07:48 -0700, Hari Kodungallur wrote:
> Currently svn provides both choices - it will store the password for
> you or you can choose to not store as well. But we could look at his
> argument as to keep the same two choices, but just make the default
> to not store the password. The config parameter can be changed by
> users if they wish to (to make store-passwords to 'yes' to make it
> store the password).
IMHO, the default should be to ask the user, as he may want to store
*some* passwords only (i.e. the least sensitive ones).
--
Vincent Lefèvre <vi...@vinc17.org> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Security flaw: subversion stores passwords by default
Posted by Karl Fogel <kf...@red-bean.com>.
Greg Thomas <th...@omc.bt.co.uk> writes:
> On Wed, 19 Mar 2008 23:07:48 -0700, "Hari Kodungallur"
> <hk...@gmail.com> wrote:
>
>>Currently svn provides both choices - it will store the password for you or
>>you can choose to not store as well. But we could look at his argument as to
>>keep the same two choices, but just make the default to not store the
>>password. The config parameter can be changed by users if they wish to (to
>>make store-passwords to 'yes' to make it store the password).
>
> I wonder if this sort of setting could be part of the repo-wide client
> configuration discussed at
> http://subversion.tigris.org/issues/show_bug.cgi?id=1974 ("server-side
> config which 'broadcasts' to clients")
I think that's a good idea, and added
http://subversion.tigris.org/issues/show_bug.cgi?id=1974#desc14
to record it.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Security flaw: subversion stores passwords by default
Posted by Greg Thomas <th...@omc.bt.co.uk>.
On Wed, 19 Mar 2008 23:07:48 -0700, "Hari Kodungallur"
<hk...@gmail.com> wrote:
>Currently svn provides both choices - it will store the password for you or
>you can choose to not store as well. But we could look at his argument as to
>keep the same two choices, but just make the default to not store the
>password. The config parameter can be changed by users if they wish to (to
>make store-passwords to 'yes' to make it store the password).
I wonder if this sort of setting could be part of the repo-wide client
configuration discussed at
http://subversion.tigris.org/issues/show_bug.cgi?id=1974 ("server-side
config which 'broadcasts' to clients")
Greg
--
This post represents the views of the author and does
not necessarily accurately represent the views of BT.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Security flaw: subversion stores passwords by default
Posted by Les Mikesell <le...@gmail.com>.
Karl Fogel wrote:
>
>> Currently svn provides both choices - it will store the password for
>> you or you can choose to not store as well. But we could look at his
>> argument as to keep the same two choices, but just make the default to
>> not store the password. The config parameter can be changed by users
>> if they wish to (to make store-passwords to 'yes' to make it store the
>> password).
>
> Sure. But we had this discussion years ago; we didn't just flip a coin
> to choose the current way, we really hashed out the pros and cons.
> (Hadmut may not have realized that, of course, since it was a long time
> ago.)
What does firefox do when you check the 'remember this password' box -
and can you use whatever library/api they use?
--
Les Mikesell
lesmikesell@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Security flaw: subversion stores passwords by default
Posted by Karl Fogel <kf...@red-bean.com>.
"Hari Kodungallur" <hk...@gmail.com> writes:
> Currently svn provides both choices - it will store the password for
> you or you can choose to not store as well. But we could look at his
> argument as to keep the same two choices, but just make the default to
> not store the password. The config parameter can be changed by users
> if they wish to (to make store-passwords to 'yes' to make it store the
> password).
Sure. But we had this discussion years ago; we didn't just flip a coin
to choose the current way, we really hashed out the pros and cons.
(Hadmut may not have realized that, of course, since it was a long time
ago.)
Best,
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Security flaw: subversion stores passwords by default
Posted by Hari Kodungallur <hk...@gmail.com>.
On Wed, Mar 19, 2008 at 10:45 PM, Karl Fogel <kf...@red-bean.com> wrote:
> Hadmut Danisch <ha...@danisch.de> writes:
> > Just read that:
> >
> > " Trust your OS to protect data on disk."
> >
> > That's nonsense. What do they believe why passwords stored by the
> > operating system are usually hashed and salted?
> >
> > What makes them believe that exactly that OS will be in place all time?
> >
> > That sort of approach is really silly. If you can't do it in a secure
> > way, than don't do it at all (at least not without explicit user
> > consent).
> >
> > 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.
>
> There are three choices:
>
> 1) plaintext passwords stored on server and client, so that crypttext
> travels over the wire.
>
> 2) plaintext travels over the wire (crypttext stored on server,
> client always has to prompt -- if client doesn't prompt, then
> "crypttext" just becomes a virtual plaintext)
>
> 3) some form of public key encryption
>
> If you are using (3), then this discussion doesn't concern you; you can
> set "store-passwords" to "no" in your config file and sleep easy. Try
> the 'svn+ssh://' access method, for example.
>
> If you're not using (3), then there are obvious tradeoffs between (1)
> and (2); use whichever way is best for you.
>
> And finally: "Don't complain; patches welcome" :-).
>
> You are complaining about bad design, but not offering any solution. If
> we *don't* store the passwords, then people will get prompted all the
> time -- we already know people don't like that; in fact, it's a
> showstopper for many users. You can see what the tradeoffs are here
> (the same as they have been forever). If you have a constructive
> suggestion to make, make it.
Currently svn provides both choices - it will store the password for you or
you can choose to not store as well. But we could look at his argument as to
keep the same two choices, but just make the default to not store the
password. The config parameter can be changed by users if they wish to (to
make store-passwords to 'yes' to make it store the password).
That is, if svn stores password, it is because the user knowingly set the
appropriate configuration value after considering the security implications
etc.
We can argue that it is the case even now, because the documentation/FAQ etc
make it very clear what svn is doing and the user has the option to turn it
off. But again, people (that includes me) RTFM only when they encounter a
problem. Until then we all think we can get it done after reading the Readme
file!
Thanks,
-Hari
PS: I have no problem with the design and I have had no issues with the
password storing issue. When I set up the repository the first time, I had
done enough experiments to know that the password was stored and I had
appropriately indicated it to our engineers. Here, I am only trying to make
sense of what is best.
Re: Security flaw: subversion stores passwords by default
Posted by Karl Fogel <kf...@red-bean.com>.
Paul Koning <Pa...@dell.com> writes:
> So... it would certainly be possible for Subversion to have an
> analogous scheme, where you run a tool (it might even be the standard
> client) with a command that says "go into the background and be a
> credentials agent for the client". That gives you the convenience of
> svn+ssh with ssh-agent, without the need to set up SSH based access
> control, and without plaintext on-disk passwords.
Yes, it's been discussed for years (search for "svn-agent"), but no one
has implemented it.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Security flaw: subversion stores passwords by default
Posted by Paul Koning <Pa...@dell.com>.
>>>>> "Karl" == Karl Fogel <kf...@red-bean.com> writes:
Karl> Hadmut Danisch <ha...@danisch.de> writes:
>> Just read that:
>>
>> " Trust your OS to protect data on disk."
>>
>> That's nonsense. What do they believe why passwords stored by the
>> operating system are usually hashed and salted?
>>
>> What makes them believe that exactly that OS will be in place all
>> time?
>>
>> That sort of approach is really silly. If you can't do it in a
>> secure way, than don't do it at all (at least not without explicit
>> user consent).
>>
>> 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.
Karl> There are three choices:
Karl> 1) plaintext passwords stored on server and client, so that
Karl> crypttext travels over the wire.
Karl> 2) plaintext travels over the wire (crypttext stored on server,
Karl> client always has to prompt -- if client doesn't prompt, then
Karl> "crypttext" just becomes a virtual plaintext)
Karl> 3) some form of public key encryption
Karl> If you are using (3), then this discussion doesn't concern you;
Karl> you can set "store-passwords" to "no" in your config file and
Karl> sleep easy. Try the 'svn+ssh://' access method, for example.
Karl> If you're not using (3), then there are obvious tradeoffs
Karl> between (1) and (2); use whichever way is best for you.
There's a bit more to the question, though.
As was already pointed out, some OSs offer a way of restricting access
to data that relies on the user password.
Another approach is suggested by how "svn+ssh" is normally used.
If you use svn+ssh by itself, you get prompted for the key unlocking
password just as often as the password prompt you get without client
password caching. In practice, many users will avoid this annoyance
by using a tool like ssh-agent (or analogous tools in packages like
PuTTY). That caches the credentials, but only in memory, not on disk,
so you're not at risk from people grabbing your disk. (You need to
avoid "hibernate" in this case, of course, and you might think a bit
about the "cold memory" attacks and how realistic they are in your
setting.)
So... it would certainly be possible for Subversion to have an
analogous scheme, where you run a tool (it might even be the standard
client) with a command that says "go into the background and be a
credentials agent for the client". That gives you the convenience of
svn+ssh with ssh-agent, without the need to set up SSH based access
control, and without plaintext on-disk passwords.
paul
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Security flaw: subversion stores passwords by default / Proposal
Posted by Karl Fogel <kf...@red-bean.com>.
"Deven T. Corzine" <de...@ties.org> writes:
> However, once you've chosen to store passwords, they should at least
> be obscured from casual viewing. Even if it's just Base64-encoded,
> that's better than plaintext passwords. At least it requires a
> positive step to decode the password, which won't happen by accident.
> An administrator could stumble across the plaintext password by
> accident, compromising the password unintentionally. No, it's no more
> secure from an attacker, but it's still an improvement.
Actually, personally I agree with that, but IIRC I lost that argument
years ago (and don't feel strongly about it).
CVS does trivially scramble passwords in just the way you describe, for
the reason you give.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Security flaw: subversion stores passwords by default / Proposal
Posted by "Deven T. Corzine" <de...@ties.org>.
Karl Fogel wrote:
> The weakness of the current way is not lack of simplicity or
> comprehensibility. It's that it stores plaintext on disk (albeit
> permission-protected). We've never claimed this is ideal; it was a
> conscious trade-off. I think any part of your suggestions that can
> purely improve the situation will be welcome. To the extent that you
> propose different trade-offs, that may or may not fly, I can't say how
> it will turn out.
>
Whether or not to store passwords at all, and whether there's a better
way, is a larger discussion.
However, once you've chosen to store passwords, they should at least be
obscured from casual viewing. Even if it's just Base64-encoded, that's
better than plaintext passwords. At least it requires a positive step
to decode the password, which won't happen by accident. An
administrator could stumble across the plaintext password by accident,
compromising the password unintentionally. No, it's no more secure from
an attacker, but it's still an improvement.
Deven
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Security flaw: subversion stores passwords by default / Proposal
Posted by Karl Fogel <kf...@red-bean.com>.
Hadmut Danisch <ha...@danisch.de> writes:
> My proposal, all I ask for is this:
>
> - Never ever store a password in clear on disk without explicit user
> consent.
> - Forget about the store* config values.
> - Provide a special command line flag --store-password
> - If that's not given, don't store the password. No default behaviour to
> store passwords,
> no accidential storage of passwords.
>
> - print a warning message *before* transmission if a password is to be
> used without wire
> encryption (i.e. a HTTP connection)
>
> If the user wants a password is to be stored:
>
> - store the server name, the protocol (HTTPS/HTTP) and the
> certificate as well (certificate is already stored, but link it to the
> password)
>
> - When a password was sent over a HTTPS connection, avoid to send it
> over HTTP. distinguish protocols.
>
> - A given password must (should) not be used automatically for any
> different SVN respository
> (could be a booby trap) .
Some of these seem like good ideas (although we should still offer a
config option for those who *want* to store passwords always). I don't
have time to evaluate them carefully, unfortunately, even though there
are many questions I would ask.
Can you propose them on the dev@ list, in a compact mail that avoids
using phrases like "bad design" to describe conscious decisions that
were publicly discussed at the time they were made, and that are not
(properly speaking) "design" questions at all?
Remember that the current defaults are the product of a *lot* of
discussion and experimentation, back when Subversion was young. The
decisions were not made lightly. Every idea that decreases convenience
to increase security will be scrutinized carefully; suggestions that
increase security without significantly decreasing convenience have a
much better chance of succeeding.
> I believe that's much more simple and comprehensible than it is now.
Hm? :-) Nothing could be more simple and comprehensible than it is now:
it is already as simple and comprehensible as it can possibly be,
namely, that Subversion remembers your password and you don't have to do
anything special.
The weakness of the current way is not lack of simplicity or
comprehensibility. It's that it stores plaintext on disk (albeit
permission-protected). We've never claimed this is ideal; it was a
conscious trade-off. I think any part of your suggestions that can
purely improve the situation will be welcome. To the extent that you
propose different trade-offs, that may or may not fly, I can't say how
it will turn out.
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Security flaw: subversion stores passwords by default /
Proposal
Posted by Stefan Sperling <st...@elego.de>.
On Thu, Mar 20, 2008 at 10:24:30PM +0100, Hadmut Danisch wrote:
> > If you are using (3), then this discussion doesn't concern you; you can
> > set "store-passwords" to "no" in your config file and sleep easy. Try
> > the 'svn+ssh://' access method, for example.
> >
> Definitely not. svn+ssh requires to have an account on the operating
> system of the server, with ability to login,
Not necessarily.
If you prefix keys with the following in the authorized_keys file,
users cannot login using the key. They can only do svn operations.
command="/usr/bin/svnserve -t",no-agent-forwarding,no-X11-forwarding,no-port-forwarding
Of course, this only works with SSH key authentication, not passwords.
Also, I share your concerns about the default storing of passwords.
I also turn password caching off. I find your proposal of an explicit
command line option interesting.
There's more people who don't like the current behaviour. The subversion
port for OpenBSD, for example, installs a global configuration file that
turns off password caching by default (in this case you can really "trust
your OS to protect your data" as stated in the SVN FAQ :-)
However, I respect decisions this project has made in the past,
and before having taken the time to read up on the old discussions
to evaluate the real reasons behind the current way password caching
is handled, I will not comment any further.
--
Stefan Sperling <st...@elego.de> Software Developer
elego Software Solutions GmbH HRB 77719
Gustav-Meyer-Allee 25, Gebaeude 12 Tel: +49 30 23 45 86 96
13355 Berlin Fax: +49 30 23 45 86 95
http://www.elego.de Geschaeftsfuehrer: Olaf Wagner
Re: Security flaw: subversion stores passwords by default / Proposal
Posted by Hadmut Danisch <ha...@danisch.de>.
Paul Koning wrote:
> So how does this avoid the security issue? The substantive change is
> that you've flipped the default to "don't store". But if it is
> stored, it's still stored on disk, in cleartext.
>
It does not store it if you don't want it.
You are still hanging on the idea that svn must authenticate automatically.
This is not always what the user wants, as the many complains about that
password thing show.
Even if you are pretty much aware of that issue and the config options,
it is
still an awful trap.
I was checking out configuration files from a svn respository
into /etc of several freshly installed computers.
On one of the computers I just forgot to change the svn config options
to not store
the password and accidently wrote the password on the disk.
Although I immediately realized this, it raises the problem how to clean
the disk again, since simply removing a file does not really help. You
need to
install wipe tools etc.
You should not put a password onto disk without making sure that the
user is
aware of this and really wants it that way.
> (Cleartext or equivalent. Absent an API where the kernel has a
> persistent copy of the user password and can use that to decrypt files
> -- which Linux doesn't have as far as I know -- even a scrambled
> on-disk copy is functionally equivalent to cleartext.)
>
> I believe the current credentials cache is already per-repository, so
> that part of your proposal is covered. Browse around
> $HOME/.subversion/auth/svn.simple, you'll see it.
>
>
Again, you still miss the problem.
regards
Hadmut
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re:
Re: Security flaw: subversion stores passwords by default / Proposal
Posted by Paul Koning <Pa...@dell.com>.
So how does this avoid the security issue? The substantive change is
that you've flipped the default to "don't store". But if it is
stored, it's still stored on disk, in cleartext.
(Cleartext or equivalent. Absent an API where the kernel has a
persistent copy of the user password and can use that to decrypt files
-- which Linux doesn't have as far as I know -- even a scrambled
on-disk copy is functionally equivalent to cleartext.)
I believe the current credentials cache is already per-repository, so
that part of your proposal is covered. Browse around
$HOME/.subversion/auth/svn.simple, you'll see it.
paul
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Security flaw: subversion stores passwords by default / Proposal
Posted by Hadmut Danisch <ha...@danisch.de>.
OK,
on the end of this mail you'll find my proposal to improve security.
Just to comment the arguments:
Karl Fogel wrote:
> There are three choices:
>
> 1) plaintext passwords stored on server and client, so that crypttext
> travels over the wire.
>
> 2) plaintext travels over the wire (crypttext stored on server,
> client always has to prompt -- if client doesn't prompt, then
> "crypttext" just becomes a virtual plaintext)
>
> 3) some form of public key encryption
>
That's not applicable because you are confusing the security mechanisms.
While that hold's true if you focus on the authentication mechanism for
one party
only without any other protection mechanism, we have a different
situation here:
svn over HTTPS with plain password authentication, so the case of 2)
protected
in a 3) layer. So security on the wire is not the problem here (of
course, if you don't use HTTP instead of HTTPS).
A typical method of protection is to use a HTTPS server to keep the SVN
repository with webdav and to
do password authentication within that SSL connection.
The mistake in your argument is that in general (although not
necesseraly) it is the server who uses public key to authenticate
against the client, while the client uses a password to authenticate
against the server.
Always keep in mind that these are different "directions".
> If you are using (3), then this discussion doesn't concern you; you can
> set "store-passwords" to "no" in your config file and sleep easy. Try
> the 'svn+ssh://' access method, for example.
>
Definitely not. svn+ssh requires to have an account on the operating
system of the server, with ability to login, while the HTTPS method just
needs the webserver to authenticate people without any need to have the
operating system know them. Furthermore, svn+ssh is too complicated and
simply a different thing.
svn+ssh is a way if the client has ssh access anyway. It is definitely
not a substitute for HTTPS.
E.g. I could give clients and business partners a password and HTTPS
access, but I would give them a ssh access to my server. And it some
cases this would be against required security standards.
Never do security the way "if there's a workaround, it ain't broken".
> If you're not using (3), then there are obvious tradeoffs between (1)
> and (2); use whichever way is best for you.
>
Again, this is wrong. Your argument is about the choice of the
authentication protocol and storage
of credentials on the server side.
I am talking about the client side who needs to keep the secret parts of
the credentials in any of the 3 methods you describe. Please be precise
about security.
> And finally: "Don't complain; patches welcome" :-).
>
Well, it would be easier and faster if those modified the source who are
familiar.
My proposal, all I ask for is this:
- Never ever store a password in clear on disk without explicit user
consent.
- Forget about the store* config values.
- Provide a special command line flag --store-password
- If that's not given, don't store the password. No default behaviour to
store passwords,
no accidential storage of passwords.
- print a warning message *before* transmission if a password is to be
used without wire
encryption (i.e. a HTTP connection)
If the user wants a password is to be stored:
- store the server name, the protocol (HTTPS/HTTP) and the
certificate as well (certificate is already stored, but link it to the
password)
- When a password was sent over a HTTPS connection, avoid to send it
over HTTP. distinguish protocols.
- A given password must (should) not be used automatically for any
different SVN respository
(could be a booby trap) .
So a good key to store the password in an local array might be something
like
https://user@server/repospath:certificate-hash
So whenever any part of this changes, a new password is to be asked for,
to avoid someone
else provoking to reveal a password.
> You are complaining about bad design, but not offering any solution.
See above. Pretty simple. Easy to implement.
> If
> we *don't* store the passwords, then people will get prompted all the
> time -- we already know people don't like that; in fact, it's a
> showstopper for many users. You can see what the tradeoffs are here
> (the same as they have been forever). If you have a constructive
> suggestion to make, make it.
>
See above. If a user wants to store the password to eliminate the need to
enter it again and again, just require him to give the option
--store-password once and
have svn store the password.
I believe that's much more simple and comprehensible than it is now.
regards
Hadmut
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Security flaw: subversion stores passwords by default
Posted by Karl Fogel <kf...@red-bean.com>.
Hadmut Danisch <ha...@danisch.de> writes:
> Just read that:
>
> " Trust your OS to protect data on disk."
>
> That's nonsense. What do they believe why passwords stored by the
> operating system are usually hashed and salted?
>
> What makes them believe that exactly that OS will be in place all time?
>
> That sort of approach is really silly. If you can't do it in a secure
> way, than don't do it at all (at least not without explicit user
> consent).
>
> 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.
There are three choices:
1) plaintext passwords stored on server and client, so that crypttext
travels over the wire.
2) plaintext travels over the wire (crypttext stored on server,
client always has to prompt -- if client doesn't prompt, then
"crypttext" just becomes a virtual plaintext)
3) some form of public key encryption
If you are using (3), then this discussion doesn't concern you; you can
set "store-passwords" to "no" in your config file and sleep easy. Try
the 'svn+ssh://' access method, for example.
If you're not using (3), then there are obvious tradeoffs between (1)
and (2); use whichever way is best for you.
And finally: "Don't complain; patches welcome" :-).
You are complaining about bad design, but not offering any solution. If
we *don't* store the passwords, then people will get prompted all the
time -- we already know people don't like that; in fact, it's a
showstopper for many users. You can see what the tradeoffs are here
(the same as they have been forever). If you have a constructive
suggestion to make, make it.
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Security flaw: subversion stores passwords by default
Posted by Vincent Lefevre <vi...@vinc17.org>.
On 2008-03-20 01:02:35 +0100, Hadmut Danisch wrote:
> Just read that:
>
> " Trust your OS to protect data on disk."
>
> That's nonsense.
Yes, even though the OS can protect data on disk, there are great
applications (run by the user) that can read them and send them
to arbitrary remote servers:
https://bugzilla.mozilla.org/show_bug.cgi?id=230606
AFAIK, this bug is still present in Firefox 2 (all versions).
--
Vincent Lefèvre <vi...@vinc17.org> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Security flaw: subversion stores passwords by default
Posted by Hadmut Danisch <ha...@danisch.de>.
Blair Zajac schrieb:
>
> See
>
> http://subversion.tigris.org/faq.html#plaintext-passwords
> http://svnbook.red-bean.com/nightly/en/svn.serverconfig.netmodel.html#svn.serverconfig.netmodel.credcache
>
Thanks, but I am pretty much aware of this.
This does not make it any less insecure. On the contrary: This is
insecure by design. If many people have
complained before, and the authors still intentionally keep such flaws,
what is their idea of security?
Just read that:
" Trust your OS to protect data on disk."
That's nonsense. What do they believe why passwords stored by the
operating system are usually hashed and salted?
What makes them believe that exactly that OS will be in place all time?
That sort of approach is really silly. If you can't do it in a secure
way, than don't do it at all (at least not without explicit user consent).
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.
regards
Hadmut
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Security flaw: subversion stores passwords by default
Posted by Blair Zajac <bl...@orcaware.com>.
Hadmut Danisch wrote:
> Hi,
>
> I just installed a subversion repository together with webdav and an
> apache server, protected
> by password authentication over LDAP and HTTPS.
>
> Accessing this repository over HTTPS worked perfectly except for a
> severe security
> problem:
>
> Unless turned off in the users (or common) configuration file,
> subversion stores the password
> in plain textfiles. Since the web access password is the same as the
> common account password
> used for several services, unexperienced users compromise their own
> passwords without even
> realizing it.
>
> Although not a bug in the common sense, this is a severe security flaw
> by design.
>
> I would strongly recommend to modify this behavior and to never ever let
> subversion store
> any password by itself. If the password should be stored locally, then
> the user should do
> it himself or at least give an option to do so.
>
> And, btw., would be nice to support the https://user@server/... syntax
> or a way to take the
> user from environment or configuration.
See
http://subversion.tigris.org/faq.html#plaintext-passwords
http://svnbook.red-bean.com/nightly/en/svn.serverconfig.netmodel.html#svn.serverconfig.netmodel.credcache
Regards,
Blair
--
Blair Zajac, Ph.D.
<bl...@orcaware.com>
http://www.orcaware.com/svn/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Security flaw: subversion stores passwords by default
Posted by Greg Thomas <th...@omc.bt.co.uk>.
On Wed, 19 Mar 2008 23:58:39 +0100, Hadmut Danisch <ha...@danisch.de>
wrote:
>Unless turned off in the users (or common) configuration file,
>subversion stores the password in plain textfiles.
Both Windows and MacOS X both use standard APIs to ensure only users
who have the OS account password can read the files -
http://subversion.tigris.org/faq.html#plaintext-passwords
They only look plain text to you because you are logged in to that
account.
Greg
--
This post represents the views of the author and does
not necessarily accurately represent the views of BT.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org