Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

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.

~/.subversion/servers:

[global]
# 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

/etc/subversion/config

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.

Ideas?

share|improve this question
    
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

2 Answers 2

up vote 4 down vote accepted

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.

share|improve this answer
    
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.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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