[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Password stored in clear text!

From: Nico Kadel-Garcia <nkadel_at_comcast.net>
Date: 2006-08-24 12:32:59 CEST

Jeremy Pereira wrote:
> On 23 Aug 2006, at 20:53, Nico Kadel-Garcia wrote:
>>> On 23 Aug 2006, at 11:30, Nico Kadel-Garcia wrote:
>>>> Well, true. It's most easily enforceable on machines where I'm
>>>> the sys-admin, and could put my copy in /usr/bin or /usr/local/bin.
>>> PATH=$HOME/unauthorisedsvn/bin:$PATH
>>> export PATH
>>> svn ....
>> Again, true. They could also create a .login message that says "My
>> Password is: XXXX".
>> But there's a practical distinction between leaving the passwords
>> lying around by default in a well-known, accessible space (and
>> having permissions of 700 is still pretty accessible, especially in
>> an NFS home directory environment or a laptop or unencrypted backup
>> environment!), and in leaving user's enough room to hang themselves
>> if they really insist.
> Talking specifically about your modified svn which does not store
> passwords, an effect of that would be your users having to type their
> passwords in lots of times which some of them might find irritating.
> It's quite conceivable that some of them would discover the
> subversion web site and download the unmodified software. It's far
> less likely that they would deliberately echo their password to the
> terminal whenever they logged in.

Oh, goodness, no. ssh+svnserve will still work using normal SSH based
keychains or ageits, as will web access that has a separate key storage
method. It's the built-in svnserve or HTTP built-in clients for subversion
that store the passwords in clear-text: The point would be to keep the
*default* subversion client from being used with its poor model for client

> You could, of course, change the client config file to not store
> their password and then explain to your users why you have done it.
> That'd probably stop them from changing it back.

Yeah, that's an approach. It requires patching a lot of accounts and
modifying people's files in them, though, rather than keeping control of the
system binaries.

To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Aug 24 12:34:21 2006

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.