[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: [PATCH] don't store plain-text passwords by default

From: Stefan Sperling <stsp_at_elego.de>
Date: Fri, 18 Apr 2008 22:42:05 +0200

On Fri, Apr 18, 2008 at 12:28:02PM -0700, David Glasser wrote:
> The problem is, it really does seem to be a bit of misdirection.

It is, by no means, intended to be THE perfect solution.

> There are some problems involving individual users being upset about
> saving the password,

The problem of users complaining is relatively harmless, even though
it puts a dent in our image from their and possibly other peoples'
point of view.

Another really bad thing is that storing plaintext passwords by default
hinders adaption of Subversion in some [commercial] environments. See
the bottom of
http://subversion.tigris.org/servlets/ReadMsg?listName=dev&msgNo=131022
for an example. I am repeating myself, I know, but it's important
to keep in mind that people posting complaints to our lists is
not the only problem at hand here.

> but IMHO the more legitimate complaint is
> *administrators* not wanting passwords saved in plaintext. Making
> this change will *not* help them: *all* of their users are going to
> run --store-password once and forget about it.

Yes, admins hate this behaviour, and this patch won't help them,
because users do things like that.

But anyone saving their passwords on disk even though the admin
told them not to will not be able to blame Subversion for doing
so behind their backs. They will have to take responsibility
themselves. They can't point at us saying "they saved my password,
I didn't do it".

> It *still* will be the
> case that an administrator will need to either use non-password forms
> of authentication, use randomly-generated passwords irrelevant to
> anything but svn, or require all users to use a specially compiled
> version of svn that ignores the new preference.

Of course. The goal isn't to replace any of these.

> It may lull them a little, but it won't actually help.

Help with what?

The goal is to make sure that as many people as possible are
instantly made aware of how bad the current situation regarding
password caching on Linux/*BSD really is the minute they start
using Subversion, so they can act accordingly.

The patch aims to help to achieve that particular goal, nothing else.

Once more and more crypto providers are added more people
can start using those instead of plaintext caching.

I'm eagerly waiting for Lieven's gnome-keyring branch to be
merged. And adding more providers for things like KDE Wallet,
TrueCrypt, or whatever else out there that can be used on *nix
is definitely something I would support.

I myself am thinking about looking into whether it's possible to add
a provider using GnuPG2 for encryption on disk, which has a gpg-agent,
similar to ssh-agent.
(BTW gpg-agent can even act as an ssh-agent, also! Quite nice.)

But all this is unrelated to how we deal with the plaintext case,
which sadly probably won't go away either.

> (On the other hand, I'd still totally support a "slightly mangle
> passwords on disk" password option so that the complaints of "I
> shouldn't find passwords by accident by grepping for them" or "I
> shouldn't have a password stick in my head because I opened the file
> by accident" are handled.)

Yes, I also think this would be much better than what we have now.

It has been done and was rejected, on grounds that it isn't THE
perfectly secure solution either, even though it's not supposed to be:
http://subversion.tigris.org/servlets/ReadMsg?listName=dev&msgNo=113647

That particular patch uses base64 encoding, oh well, bit better than
rot13 I guess, but should keep passwords from sticking in peoples'
heads by accident.

+1 on reusing that patch, along with either a notification that informs
users that the password is not stored in a secure way (requiring
some form of interaction to get rid of the message), or a
mechanism similar to my patch that forces people to explicitly
tell Subversion to store their password in an insecure way.

A combination of scrambling and forcing a decision to be made
is even better than my current patch.

-- 
Stefan Sperling <stsp_at_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

  • application/pgp-signature attachment: stored
Received on 2008-04-18 22:42:21 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.