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
