This thread has been dormant for a while, but the question hasn't
gone away. It would be great if we could reach a consensus. Here
is a combined proposal (based on proposals quoted below from
Daniel Sahlberg and Stefan Sperling):
1) Re-enable plaintext passwords in compile time defaults.
2) Disable plaintext passwords in default runtime configuration.
Users can re-enable it in their configuration when they want
it.
3) When running a regular Subversion command like 'update' or
'commit',
if authentication is required and there is a "safe"
password-storage mechanism available (such as kwallet or
gpg-agent or whatever), then that safe mechanism would be used
automatically, as it is today.
But if no safe mechanism is available, *then* the user would be
told to run 'svn authn' (see below).
4) There is a new 'svn authn' command to authenticate to any
repository. E.g., 'svn authn [ --username jrandom ]
REPOS_URL'.
See detailed description of it below.
The new 'svn authn' command is a generic entry point to
authentication-related functionality.
If you run 'svn authn' and a "safe" password-storage mechanism is
available, then it'll just store the password using that mechanism
-- the same way 'update' or 'commit' would have done.
But when no safe mechanism is available, then 'svn authn' will
print the big warning message that svn traditionally printed when
about to store a plaintext password, and then, if the user
indicates "yes", caches the password in plaintext in the same way
we did before.
Notice that, in practice, users will only be steered to 'svn
authn' when there is no safe mechanism available, becuase
otherwise whatever regular svn command they were running would
have simply used the safe mechanism.
Thus, users will not become habituated to using the 'authn'
command. It'll be a rare event, and the user will be aware of
what she's doing and be likely to read and understand the warning
about plaintext password storage, instead of skimming or ignoring
that warning because she's right in the middle of a common
end-goal operation like 'update' or 'commit' and just wants to
complete it as fast as possible.
('svn authn' could also support a '--remove' flag to clear out the
authn cache for a given repository. It could also support
wildcards / offer a way to clear auth for all repositories / offer
a --remove-plaintext-passwords option to clear all plaintexts,
etc. The point is, with this new subcommand, we would now have a
UI entry point to a number of cleanup / change-one's-mind
features.)
I suggest the command name 'authn' rather than 'auth' in order to
keep "authentication" (authn) distinct from "authorization"
(authz). Although though we don't have an "authz" subcommand,
Subversion does have server-side authz features, so keeping this
distinction clear seems worthwhile. However, I don't feel
strongly about it -- if everyone prefers "auth", I'm not going to
argue too hard :-).
Thoughts?
Ever since Subversion removed plaintext password caching, I have
watched users lives get harder (some of our company's trees are in
Subversion, so I get to watch a diverse group of people use
Subversion on a regular basis close up, and I heard the complaints
about this change).
Generally, a user knows enough about her actual threat model to
make informed decisions about whether to cache passwords locally.
And there are many situations in which the convenience of local
caching is *immense*, especially when automating Subversion
operations.
The decision (see r1845377) to disable password caching took away
users' ability to use their domain knowledge to make those
informed decisions. The justification was that sometimes people
might unknowingly put themselves risk -- while the threat model
might be rare, the consequences could be severe. This is
understandable, but I think in the end we picked the wrong place
on the security/convenience trade-off spectrum. The loss of
convenience is so huge that it's a make-or-break usability
question for many people.
While we can't reduce the risk to *zero*, we can reduce it pretty
far by implementing 1-4 above.
(By the way, by "plaintext" I just mean "not strongly encrypted".
I don't care if we rot13- or base64-encode it or whatever -- those
seem like good ideas, to avoid non-malicious exposure events, but
IMHO doing or not doing that encoding isn't central to this
proposal.)
Things like kwallet / gpg-agent / etc are great and I use them
every day, but they are not trivial to set up nor reliable for
many users. They also aren't available in some situations anyway
(again, especially in automated operations in constrained
environments).
Best regards,
-Karl
On 24 Aug 2021, Stefan Sperling wrote:
On Mon, Aug 23, 2021 at 09:05:33PM +0200, Daniel Sahlberg wrote:
Has there been any complaints about Subversion's ability to
store passwords
in plaintext?
Of course :) Years ago, before any encrypted storage was
available
on Unix systems, this was a common complaint.
The FAQ entry which you improved in
https://svn.apeche.org/r1887129
was previously using language which reflected the nature of
complaints
that were received: "Ahhh! I just discovered that my Subversion
client
is caching passwords in plain-text on disk! - AHHH!"
(I tried to search the mailing list but didn't come up with
anything, possibly because of a lack of imagination on proper
keywords).
Maybe these complaints would have gone to the different
distributions?
Perhaps some of them arrived via internal support channels of the
various
companies involved in SVN's development. Not all communication
with users
occurs via public channels.
For reference, here is the e-mail where Stefan Sperling
mentions the change
in OpenBSD to re-enable support for plaintext passwords in
OpenBSD: [2] I
would encourage everyone to re-read that message since it has a
good
summary of arguments (including a link to a request from a
corporate
security group to TortoiseSVN to avoid storing a password in
plaintext in
memory).
For me the route taken by OpenBSD seems reasonable:
- Enable plaintext passwords in the compile time defaults
- Disable plaintext passwords in the default runtime
configuration
- Let the users re-enable it in their configuration if they
want to
Pros:
* It would not change the default behaviour.
* It would enable users to enable plaintext passwords in
configuration
without having to recompile.
Cons:
* Potentially some security group would argue about the
possibility to
enable plaintext passwords at all.
As someone who supported the original change to disable this
feature at
compile-time, I backtracked a bit when I saw the consequences on
OpenBSD
servers where unattended operation of svn in scripts is
relatively common.
But I still think that Brane's concerns are warranted.
In particular (from #svn-dev IRC just now):
09:30 <@brane> the only issue i have with that is that users
rarely look at
~/.subversion/config and may not even be aware
that the option
is enabled.
A potential attack would be Alice leaving her desktop unlocked,
and Eve using this chance to enable the option in Alice's config.
Eve would also clear the password cache with svn auth --remove
and disable the plaintext password prompt by setting the
appropriate
option in ~/.subversion/servers.
Now Alice comes back and uses SVN as usual, unaware that her
password
is being cached in plaintext, perhaps assuming it is being cached
in
encrypted storage as she would reasonably expect.
When Alice leaves her desktop unlocked another time Eve collects
Alice's SVN password from plaintext storage.
The above may seem ridiculous to some (after all, Alice should
not have
left her desktop defenseless!) but this is indeed a threat
scenario
which is considered in some deployments. The TortoiseSVN
discussion
linked earlier is based on a similar threat model where an
unlocked
Windows desktop is abused to spy out passwords cached by
TortoiseSVN,
which will reveal encrypted passwords in plaintext when asked to
do so.
To protect Alice from this attack, writing plaintext passwords
must
remain disabled during regular usage of SVN. We could provide a
special
mechanism to add a plaintext password under a set of conditions:
- The command to run is not a regularly used SVN command.
'svn auth' would be a good candidate since its sole purpose
is to inspect and manage the cached credentials store.
- The user provides the password and authentication with this
password against the server succeeds.
- If a non-plaintext storage backend is available, that backend
is used instead of storing the password in plaintext (but
perhaps
the plaintext backend could be forced via a command line
switch).
- The user gives consent to the password being stored in
plaintext
by answering 'yes' to the plaintext password prompt, in a way
that
cannot be overridden by configuration files (i.e. the value
of the
store-plaintext-passwords option in the servers configuration
file
would be ignored by this command).
We could have 'svn auth add https://svn.example.com/svn/foo' as a
one-shot operation that satisfies the above constraints, while
leaving
all other code paths compiled out which would otherwise store
passwords
in plaintext. A regular 'svn update' still won't cache a password
in
plaintext, unless --enable-plaintext-passwords was passed at
compile-time.
Now Alice can store a plaintext password (and will be aware of
its existence),
but Eve cannot fool Alice into doing so unless Subversion was
compiled with
the --enable-plaintext-passwords option.
Would this work?
Regards,
Stefan
