Re: plaintext passwords - my 0.02c

Paul,

most are aware that subversion (mod_dav_svn) allows for single-sign-on which is very well suited for security minded corporate environment and no passwords are ever transmitted (when used with GSSAPI/Kerberos - KrbMethodK5Passwd off) and no passwords are stored either. This should also be possible to setup with svn+ssh with ssh (+ GSSAPI) although i have not yet had need to test it.

You will agree above is better thn having to store password clear text or encrypted or encoded irrespective.

so IMO, your conclusions are invalid and ur 0.02c worth not correct. If one wants secure setup, they need to set it up secure, grounds up. Subversion doesnt restrict you, infact it allows u to use security model best suited to ur requirements.

If you need help, look thru mailing list archives or ask this list or other resources.

regards

Shirish

  ----- Original Message -----
  From: Paul J R
  To: users@subversion.tigris.org
  Sent: Tuesday, July 18, 2006 11:00 PM
  Subject: plaintext passwords - my 0.02c

  I've worked on two projects in the last 6 months where svn has been put forward as an "option" and both times its been passed over in favor of things like rational.

  Fair enough, its been big corporates that I've been working for who value the perceived security they get with products like rational, but both times the same thing has happened. The project goes to get security approval for the various options they have on the table and svn is thrown out by the corporate security groups as an option. Both times, svnserve wasn't even considered to be something that was going to be used, but both times the same argument was thrown in:

  "well, if the guys who code subversion are willing to have passwords kept on the OS in plain text, how many other problems exist in their code?"

  To which there is no real answer.

  The sad fact is that the minimum security level is always one-way hash or two factor auth'ing in those environments. I asked one of the guys to send me an email about why this all comes about and his response was mostly what I expected but he had a few points I hadn't thought of (im paraphrasing here):

  -----

  We consider nothing secure (OS, software, hardware, all of it), no matter how up-to-date anything is and no matter how isolated it is from the any other network the potential for someone to "break in" exists (that's the basis from which we work). Keeping plain text passwords anywhere on a system is essentially "giving them away for free", and any hacker that managed to get that close will see the svnserve port open and it's a red-flag for them "hey, free passwords here". Now assuming they managed to hack into the box (and they may not even have to do that), theres no telling what those passwords give them access to. Obviously a certain amount of intelligence will tell you that "a password policy is in order", unfortunately policy is never a real answer to anything. No matter what you tell the users to do, they almost always end up ignoring it cause its "too much hassle" unless you can enforce it, and that's something else svnserve cant realistically do. Even worse, if we implemented some way of checking what the user selected as a password as not being a password they're using anywhere else, and they did the damage has already been done. The password is now in the OS file system somewhere, so what do you do? DOD erase the entire drive? Disable their account across every environment we find they're using the same one? That's an extreme amount of work considering the number of environments potentially impacted, not to mention the waste of the person who now has to call a helpdesk somewhere and sort the situation out (even if it was their own stupidity in the first place). I also said they may not have to break into the OS to get the passwords, which is the second problem with it; What if someone found a hack (buffer overflow, remote execution flaw, etc) in the daemon that allowed the user to just dump the password file from remote? That's an even more troubling scenario.

  Now with your project, you weren't going to use svnserve, and instead were heading for webdav option. Considering the code that drives svn's webdav is probably written by the same people who would put plain text passwords on the OS, the same level of trust has to be assumed. Unfortunately that's quite low, any developer who considers keeping plain text passwords on the file system of the OS and relying on the OS's own security for protecting it is living in a dream world. I can even bet you money that the daemon doesn't even go to any lengths to protect that file (i.e. doesn't even complain if the file is world-readable). Now if they had just made the file encrypted on disk and force you to enter a password to start the svn server daemon to unecrypt the file (like the way apache keeps its keys), then that's 100 times better (not perfect mind you because if you can make the daemon dump its memory in some way you would probably still get the passwords, but at least it's a level of security that is acceptable).

  Now obviously there's a lot of software out there we use that has exactly the same problems (for example with apache you can keep the key on-disk unencrypted), but none of the products we use give you the potential to gain a real-user password like a corporate lan login. But this is also why we go through each project on a case by case basis. Considering the people who would be using subversion in this environment are fairly "trusted" users who have access to some very sensitive customer information, the risk is quite large. User logins in most environments always have the largest potential for causing damage and we do as much as we can to mitigate the risk. Sadly, the users themselves are usually the biggest problem but we're not in the business of adding to that risk even in the smallest possible way.

  Using subversion may save you a lot of money (compared to the many dollars you'll spend implementing rational), the project code base may even be quite small and the code itself may be of no value to a hacker (in fact, everything on the server running subversion may not help a potential hacker or be of the slightest use to them). The reality of the situation is I have to ask the question "what else could a hacker gain access to if they got access to that password?" (irrelavent in your environment I know) but then I have to ask "how can we trust code that would allow it in the first place?", and the answer is you cant. We would be negligent to sign off on any project using subversion for just those reasons.

  -----

  The way I read all that is simply to say that because subversion's daemon allows this kind of behavior its sadly devalues everything that subversion is. Sure it's a big corporate that can afford a commercial product, but its sad to see svn pushed aside from such a small issue really.

   
Received on Tue Jul 18 15:54:15 2006