You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@subversion.apache.org by Daniel Sahlberg <da...@gmail.com> on 2021/10/03 10:38:48 UTC

Re: A strong WTF on compiling out plaintext password support by default?!

Hi,

I would like to reboot this thread once again. I have read through all
messages and I have tried to make a summary of the important points. The
date/time references are as seen in
https://mail-archives.apache.org/mod_mbox/subversion-dev/.

There are numerous descriptions of problems with the different keyrings. I
think the most important are:
- Some requiring GUI boxes to unlock, even showing GUI boxes on the local
display while running over SSH
- No easy way to work with the keyrings non-interactive

The original request was to find some way to store credentials in the
plaintext cache.

Two different solutions have been presented:
- Reverting the compile time default to enable the plaintext password
store, while setting runtime configuration options to disable it, following
the example set by OpenBSD.
Four persons seem to have expressed support for this idea (Mark Phippard,
Johan Corveleyn, myself (2021-08-26 13:34 to 2021-08-27 07:56) and Martin
Edgar Furter Rathod (2021-08-31 12:46)). The former three prefering it over
the svn auth, but accepting the idea of svn auth. Martin suggested to move
the plaintext support to a separate library that could be installed
separately (or removed after installation), no-one picked up this idea.

- Adding an svn auth add command
One person seem to have expressed support for this (Stefan Sperling
(2021-08-24 08:27 and again 2021-08-27 12:40)). The first message is the
earliest suggestion of svn auth add that I can find. In the latter message,
Stefan clarifies that he belives svn auth add is the better design but
wouldn't stand in the way of consensus. He also wrote he had been willing
to invest time in writing the code for svn auth add but not for switching
the default compile-time behaviour.
Regarding the need to validate the credentials with the server, it seems
this was based on pseudocode by Johan Corveleyn (2021-08-24 14:25) doing
svn ls, and then asking for a new password if svn ls failed. It was
mentioned by Daniel Shahaf that svn ls might succeed even if the
credentials were incorrect (as with svn.apache.org offering anonymous
access) or that the check only verified "r" access and later code might
require "w" access.
It seems to be a general agreement that it is currently not possible to
validate if some credentials have a certain level of access to a certain
path, in a general case. It was suggested to add RA API calls, but these
would only work with new versions of both the server and the client.
There has been a significant discussion whether to verify the credentials
and whose responsibility it is to store correct credentials (with
appropriate access).

---- This is the end of the summary. Below are my personal reflections

I have ignored the discussion regarding rethorics since I hope we can
continue without it. If someone feels hurt because of the discussion I hope
it can be worked out without affecting the future discussion in this
thread. I think all contributors have come with valuable input on the
design questions so far.

It seems most messages are concerning the svn auth add solution. To add
this command without contacting the server seems to be quite a bit of code
but not impossible. It would also be a client-side only solution not
requiring any specific server version. To add support on the server side
might be difficult, especially considering that (part of) the
authentication/authorization might be done outside of the Subversion code.

The decision to change the compile time default was made in 2018-10-31
within less than 12 hours and without much debate. It was committed less
than 19 hours after the initial message.
I'm assume the impact of an incorrect password in the store is application
dependant but a password can grow stale even if it was correct at the time
of writing so the administrator would have to manage this anyhow. From my
point of view, verifying the credentials is nice but not necessary to solve
the initial use case.

Until we completely remove the possibility to read the plaintext store
security conscious organisation might have issues. Having svn auth add as
an official command makes it more obvious that this possibility exists -
instead of users running unofficial scripts or even manually editing the
config files. Anyone who feel it should not even read the plaintext
password store could convince their vendor to remove it or roll their own.

---- Below is  my understanding of the decision tree and my proposal:

The first point where we must reach agreement is whether or not to do
anything at all:
 * There has been several complaints from several different users over
   the last years who's workflow has been interrupted. There may be users
   or organisations who disprove of storing passwords in the plaintext
   stores. Whatever we choose there will be someone who feels we make
   the wrong choice.
 * If we decide it is a reasonable use case store passwords in plaintext
   and that we should support writing this store we need to decide which
   solution to use:
    * Revert r1845377 and enable plaintext password store by default. I
      have not been able to find any complaints in the public archives
      about subversion's ability to store passwords in plaintext. As
      pointed out by Stefan Sperling (2021-08-24 08:27) there was a FAQ
      entry based on the nature of complaints received, some that might
      have gone directly to the companies involved in Subversion
      development.
    * Create an svn auth add command. This option has the advantage that
      one person has expressed interest to invest time to write the code.
    * Script in contrib. The least visible option and several people
      have expressed that it will be difficult for them to maintain a
      local copy of the script. Only advantage is that it gives us
      plausible deniability: "Subversion doesn't store passwords but
      we can't prevent your users from downloading a script and using".
 * If we go for svn auth add we must decide how important it is to
   verify that the credentials have the correct access.

Based on the reasoning above I'm proposing:
- Adding an svn auth add command that more or less does what the scripts
are already doing. It should require typing the password in a loop until
repeated correctly but not do anything to verify that the password is
correct. Anyone requiring to validate the password can do it with an
appropriate svn command based on their authn/authz setup and their
requirements.
- Adding this in SVN 1.15.0.

I don't have much time to contribute but I will help as much as I can in
testing.

Kind regards
Daniel Sahlberg

Re: A strong WTF on compiling out plaintext password support by default?!

Posted by Mark Phippard <ma...@gmail.com>.

Thanks for taking the time to summarize the thread as well as the
additional research you added.

On Sun, Oct 3, 2021 at 6:39 AM Daniel Sahlberg
<da...@gmail.com> wrote:

> The decision to change the compile time default was made in 2018-10-31 within less than 12 hours and without much debate. It was committed less than 19 hours after the initial message.

I had been wondering about this. It is interesting how quickly such an
impactful decision was made. My recollection is that it was one of
those "security trumps everything else" arguments where the impact was
just brushed away. I kind of wish someone would just make the equally
quick decision to reverse this commit so it could all be discussed
again as I obviously think it was the wrong decision.

> Until we completely remove the possibility to read the plaintext store security conscious organisation might have issues.

Exactly. This is why my preference is to put the feature back by
default and if we do anything it should be to have a compile time
option that security conscious orgs can use to completely remove the
possibility.

As I was responsible for the SVN product @ CollabNet for 14 years most
of these customer complaints made their way to me eventually. I do not
want to go so far as to say customers were satisfied with all of the
warnings and options we had added over the years to give them some
control over the plaintext feature, but I do recall most of the
questions stopped coming in. What customers wanted was password
caching that was more secure. I cannot recall a single customer that
was ever satisfied with GNOME, KWallet or GPG options. I actually
think most of them would have been happier if we just stored the
password as a Base64 or ROT13 string .. of course they would have
preferred some kind of encryption.

I am sure we had a handful of customers that had a security team that
would be happy with the new defaults because their mission is security
and they do not care what havoc it wreaks on developer productivity.
That said, these types of customers would probably be extremely
unhappy if they realized there was a backdoor way to still have a
plaintext password stored and used. So this type of user will not be
happy with the svn auth add approach or the fact that there is a
scripting option out in the wild.

This is why my suggestion is we put things back the way they were
prior to this change with all of the warnings and options we had etc.
Then, what is really needed, is a compile time option that 100%
removes all support for a plaintext password, even ones that are
already stored.

Finally, it has always been rejected out of hand as silly or
deceptive, but I would just reiterate that most of these customers
would be happy if we just used Base64 to store the plaintext password.
We could also use real encryption and they would be even happier. The
problem with that of course is the key. I would suggest we just store
the default key in the source code. We know it is not truly secure but
it would at least require non-trivial scripting that was specific to
our encryption and we could support a compile time option to supply a
different key which would actually make it fairly secure. We made a
custom SVN client for one customer where we essentially did this for
them. We told them the tradeoffs and that it was not really security
but it was what they wanted and it satisfied their audits and
requirements. Given that I am no longer @ CollabNet I cannot really
help in terms of sharing the code we wrote. I know it was a hack for
sure and not done in a way that we would commit as is.

Thanks

Mark