By default, Subversion allows users to save their password in plaintext in ~/.subversion/auth/svn.simple. I'm investigating options for storing encrypted passwords in svn, but at the very least and ASAP, I want to completely disable the ability to store passwords for all of our users. We are running Subversion 1.6.17.

I can disable this within a user's home directory via the config file.


# Password / passphrase caching parameters:
store-passwords = no
store-plaintext-passwords = no

However, the user could change the config file if they wanted to. Is there not a system-wide svn config file? A few options I've seen:

Option 1

In 1.8-dev, Subversion's configure script accepts a --disable-plaintext-password-storage option to bypass the logic which stores plaintext passwords and client certificate passphrases.

I prefer not to update to a development release.

Option 2


AFAIK, this config file is only used when a user doesn't have a config file already in their home directory.

Option 3

Add a cron job to delete the user's auth cache in ~/.subversion/auth/svn.simple. So, even if they alter their svn config file, then our cron job would kill any stored passwords. However, even running it every minute doesn't guarantee that our backup system wouldn't grab the file(s) containing plaintext passwords.


  • Do you control the server? Why not use SSH plus key, or Kerberos instead of password authentication? – Mikel Jul 18 '12 at 0:51
  • yes I'm the admin. – Banjer Jul 18 '12 at 15:08

You can't.

Whatever you do, your users can bypass it and store their password in a plain text file anyway. If you disable the feature in the client binary, they'll download or compile a different client. As a rule, if you set up obnoxious security measures (such as having to type a password for every svn operation), your users will bypass them in a way that makes security worse. (For example, writing a wrapper script that contains their password. Which they'll leave world-readable.) So don't do that.

To reiterate: you cannot, by technical measures alone, prevent users from storing their password in a file. You can forbid it, but if it makes their life difficult, they'll do it anyway.

If you're concerned about laptop or backup theft, encrypt the users' home directory. This will protect the passwords as well as the data. If the whole home directory is encrypted, the encryption password is usually the same as the login password, for usability reasons. Be sure to have a password backup policy (e.g. a sealed envelope), since losing an encryption password is irrecoverable.

If you're concerned about password reuse, impose a random (hence unique) password, which they will type once and for all into their client. Have a simple process for changing compromised passwords, of course.

  • Great points all around. I have certainly seen users circumvent protocols we have in place in order to make their life easier. I'll have to see what else svn offers in the way of authentication that doesn't annoy users, such as key-based. – Banjer Jul 18 '12 at 15:13

BTW even before encrypting anything, I would take care of file permissions: just checked my own setup out of curiosity, and found out this is world readable. For a file containing a clear password, it looks to me like a security hole.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.