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/20 21:24:30 UTC
Re: Security flaw: subversion stores passwords by default / Proposal
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 / 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