You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Roland Schwingel <Ro...@onevision.de> on 2003/09/19 07:45:54 UTC
Authentication - storing of passwords in ~/.subversion/auth/svn.simple
Hi....
As of the fact being back from honeymoon, I started out again to migrate my
CVS to SVN. I updated to 0.29 and added authentication to httpd for svn.
This works very well...
BUT: I encountered that subversion client stores my passwords in
*CLEARTEXT* in ~/.subversion/auth/svn.simple/<some_file>. This is IMHO not
so nice. Storing of passwords is ok, so that it can remember it for
subsequent use, but it should encrypt the stored password in someway that
only subversion can use it again...
Have I overseen something in config or is it missing??? It it is missing it
should IMHO be added...
What can I do to prevent storing my password in cleartext? (except
disabling storing it) in ~/.subversion/config?
Thanks for your help...
Roland
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Authentication - storing of passwords in ~/.subversion/auth/svn.simple
Posted by Benjamin Pflugmann <be...@pflugmann.de>.
Hi.
On Fri 2003-09-19 at 11:26:37 +0200, you wrote
> Hi David and List....
>
> > Which mechanism of 'encryption' would you suggest? rot13? base64
> encoding?
> Well an encryption which at its best can only be read by svn client to
> decode it back in clear to send it to apache. I know that someone capable
> enough to program can extract the algorithm out of the sources and decrypt
> the password by then.
David already addressed this, but maybe it came not over clear enough.
No need to be very capable, extract any algorithms or such: If you can
compile subversion, everything needed is one printf statement after
the part when the password has been decoded and a recompile. Even most
non-programmers are able to do this.
> The 'encryption' should be strong enough to hide the real password
> from human eyes by just opening a file in the editor, especially
> when your authentication mechanism you use in apache reads users
> data from a global authentification mechanism where you only have
> one unique password for everything. If it is detectable by just
> knowing where to find a single file the whole security is gone.
Well, even if the file was encrypted, there never was any real
security. Just some easy-to-be-broken obscurity.
How strong the encryption is, doesn't change the work for the
attacker, because he doesn't attack the encrypted file, but simply
decrypts it with the readily available algorithm and key from the
subversion source. Any security measure is only as strong as it's
weakest link. And in this case it's the accessibility of the file.
So, encryption doesn't help at all, except for one thing: it has do be
an intentional attack. Someone just glancing over the file, wouldn't
see the password. And that can be as easily be archieved by some
simple encoding mechanism, like base64, as David explained.
That was also why he went on to suggest to rely on filesystem
security. It is a lot safer, because it requires an attacker to obtain
at least root privileges, instead of just recompiling a program.
> > My suggestion is to rely on filesystem-level security to protect
> > the password files. If you want to defend against really stupid
> > attackers who don't know how to do google searches, promote base64
> > [...] If you cannot rely on filesystem-level security, don't
> > store passwords to disk.
>
> In my eyes you cannot rely on that...
Well, then the answer is clear: don't store passwords on disk.
This is not a new kind of problem. Security experts have discussed for
years how to protect data, that is meant to be processed without user
interaction, and there is no holy grail in sight[1]. Usual advice is
what David said: use the permission system of your OS.
[1] Another typical application of this are scripts for web sites
which shall access a database with sensitive information. Anybody
getting control of the scripts, also obtains the means to access the
sensitive database.
[...]
> But even you imagine the fs level security is working, this will not
> "defend" a user who has root-access to the machine.
If you cannot trust the root user on the machine to leave your files
alone, you should not store/process *any* sensitive data on that
machine.
> He can read the file regardlessly of the permissions and so can get
> the cleartext password, which is elsewise completely hidden to
> him.
Completely hidden is a bit of a overstatement. As I said, just a
one-line change and a recompile... Yes, it protects against the casual
bystander, as mentioned above.
> When it is encrpyted in some way the burden to him to get it
> cleartext is much higher. I still suggest to encrypt the stored
> passwords, even I can understand your (David) points.
If you meant someone "getting" root: Well, that usually requires a
more effort than recompiling some program. Also, I only need a one
time access to the file, to copy it away, and then have as much time
as I want to crack it (although adding the printf can be done quickly,
the compile may take a while ;-).
> > (Sorry if this came off as a rant, this same thread has come up three
> > times now this week on different mailing lists I subscribe to. Believe
> > it or not, I edited this post down... twice.)
> Ooops.. I just browsed very fast over the subversion users mailinglist and
> couldn't find an appropriate thread. Didn't want to hit a wound point.
I think he didn't meant the Subversion list, but other lists.
> Roland, who is not wanting to start an ideologic war here, just
> noticing a (in my eyes) security design flaw.
Well, this is a thing that may often perceived as flaw, but isn't one.
Having the password stored on disk brings a certain risk. But it only
would be a flaw, if storing the password as plaintext would cause the
risk to be (significantly) larger.
Another one of that kind (perceived flaws) is a world-readable file
within a protected directory. There is absolutely no more risk as with
an protected file, it only got changed finally, because the develit got
reported often.
In fact, I would even like to veto against introducing such an
(effectively pseudo-) encryption, because it provides a false sense of
security. The current behaviour had the right effect for you: you
realized that safing the file on disk is a risk which you are
seemingly not willing to take.
Would you have noticed that, too, if the file had used some simple
encoding?[2]
Regards,
Benjamin.
[2] I hope I could convince you that in this case encryption does not
has any merit over some encoding, as long as the encoding cannot
easily deciphered by humans without tools (that's why I didn't
suggest rot13, which is too easy to read).
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Authentication - storing of passwords in ~/.subversion/auth/svn.simple
Posted by Jan Evert van Grootheest <j....@euronext.nl>.
Roland,
In unix land it is not so uncommon to rely on the filesystem. For
example, fetchmail uses a .fetchmailrc file in the users' home directory
and contains the usernames and matching passwords for all mail (s)he
wants to retrieve. Fetchmail actually refuses to work if this file has
the wrong permissions.
In your situation I also don't understand the problem.
If samba exports the homes, then the user logged into windows can access
only his own home directory. If it is different, I'd say samba can be
reconfigured to provide the proper protection.
Something like this should do the trick in smb.conf (from the example
configuration):
[homes]
comment = Home Directories
browseable = no
writable = yes
valid users = %S
create mode = 0664
directory mode = 0775
-- Jan Evert
Roland Schwingel wrote:
>
>
>
> Hi David and List....
>
>
>>Which mechanism of 'encryption' would you suggest? rot13? base64
>
> encoding?
> Well an encryption which at its best can only be read by svn client to
> decode it back in clear to send it to apache. I know that someone capable
> enough to program can extract the algorithm out of the sources and decrypt
> the password by then. The 'encryption' should be strong enough to hide the
> real password from human eyes by just opening a file in the editor,
> especially when your authentication mechanism you use in apache reads users
> data from a global authentification mechanism where you only have one
> unique password for everything. If it is detectable by just knowing where
> to find a single file the whole security is gone.
>
>
>>My suggestion is to rely on filesystem-level security to protect the
>>password files. If you want to defend against really stupid attackers
>>who don't know how to do google searches, promote base64 - this is what
>>the vast majority of 'encrypted' passwords for network-enabled apps are,
>>because they still have to 'decrypt' to plaintext. If you cannot rely on
>>filesystem-level security, don't store passwords to disk.
>
> In my eyes you cannot rely on that... Eg (like here) you have a linux box
> with the users homeaccounts and samba to share the filesystem to the
> clients and you use subversion on cygwin you are running very fast in
> exactly this situation. The auth and/or .subversion folder and their
> contents created by svn have 755 permissions on the linux box, so everyone
> can read them (This is a cygwin<->samba problem). You need to chmod at
> least the auth folder from the linux machine to protect the password.
> But even you imagine the fs level security is working, this will not
> "defend" a user who has root-access to the machine. He can read the file
> regardlessly of the permissions and so can get the cleartext password,
> which is elsewise completely hidden to him. When it is encrpyted in some
> way the burden to him to get it cleartext is much higher. I still suggest
> to encrypt the stored passwords, even I can understand your (David) points.
>
>
>>(Sorry if this came off as a rant, this same thread has come up three
>>times now this week on different mailing lists I subscribe to. Believe
>>it or not, I edited this post down... twice.)
>
> Ooops.. I just browsed very fast over the subversion users mailinglist and
> couldn't find an appropriate thread. Didn't want to hit a wound point.
>
> Roland, who is not wanting to start an ideologic war here, just noticing a
> (in my eyes) security design flaw.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Authentication - storing of passwords in ~/.subversion/auth/svn.simple
Posted by Ben Collins-Sussman <su...@collab.net>.
Roland Schwingel <Ro...@onevision.de> writes:
> Roland, who is not wanting to start an ideologic war here, just noticing a
> (in my eyes) security design flaw.
There's no security flaw here; this has been discussed many times in
the past. ~/.subversion/auth/ is set to chmod 700. That means no
spying eyes can look at your cached cleartext passwords.
If you don't want the caching to happen at all, just set
[auth]
store-password = no
...in your ~/.subversion/config file. End of story.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Authentication - storing of passwords in ~/.subversion/auth/svn.simple
Posted by Roland Schwingel <Ro...@onevision.de>.
Hi David and List....
> Which mechanism of 'encryption' would you suggest? rot13? base64
encoding?
Well an encryption which at its best can only be read by svn client to
decode it back in clear to send it to apache. I know that someone capable
enough to program can extract the algorithm out of the sources and decrypt
the password by then. The 'encryption' should be strong enough to hide the
real password from human eyes by just opening a file in the editor,
especially when your authentication mechanism you use in apache reads users
data from a global authentification mechanism where you only have one
unique password for everything. If it is detectable by just knowing where
to find a single file the whole security is gone.
> My suggestion is to rely on filesystem-level security to protect the
> password files. If you want to defend against really stupid attackers
> who don't know how to do google searches, promote base64 - this is what
> the vast majority of 'encrypted' passwords for network-enabled apps are,
> because they still have to 'decrypt' to plaintext. If you cannot rely on
> filesystem-level security, don't store passwords to disk.
In my eyes you cannot rely on that... Eg (like here) you have a linux box
with the users homeaccounts and samba to share the filesystem to the
clients and you use subversion on cygwin you are running very fast in
exactly this situation. The auth and/or .subversion folder and their
contents created by svn have 755 permissions on the linux box, so everyone
can read them (This is a cygwin<->samba problem). You need to chmod at
least the auth folder from the linux machine to protect the password.
But even you imagine the fs level security is working, this will not
"defend" a user who has root-access to the machine. He can read the file
regardlessly of the permissions and so can get the cleartext password,
which is elsewise completely hidden to him. When it is encrpyted in some
way the burden to him to get it cleartext is much higher. I still suggest
to encrypt the stored passwords, even I can understand your (David) points.
> (Sorry if this came off as a rant, this same thread has come up three
> times now this week on different mailing lists I subscribe to. Believe
> it or not, I edited this post down... twice.)
Ooops.. I just browsed very fast over the subversion users mailinglist and
couldn't find an appropriate thread. Didn't want to hit a wound point.
Roland, who is not wanting to start an ideologic war here, just noticing a
(in my eyes) security design flaw.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Authentication - storing of passwords in ~/.subversion/auth/svn.simple
Posted by David Waite <ma...@akuma.org>.
Roland Schwingel wrote:
>
>
>Hi....
>
>As of the fact being back from honeymoon, I started out again to migrate my
>CVS to SVN. I updated to 0.29 and added authentication to httpd for svn.
>This works very well...
>
>BUT: I encountered that subversion client stores my passwords in
>*CLEARTEXT* in ~/.subversion/auth/svn.simple/<some_file>. This is IMHO not
>so nice. Storing of passwords is ok, so that it can remember it for
>subsequent use, but it should encrypt the stored password in someway that
>only subversion can use it again...
>
>
Which mechanism of 'encryption' would you suggest? rot13? base64 encoding?
The password can be 'disguised', but anything the subversion program can
do to undesguise the password, someone with access to the .subversion
directory and subversion binary can do as well. The cleartext password
is required for plain authentication.
The only feasable 'secure' mechanism would be to require HTTP digest
authentication, and to store the A1 digest instead of plaintext
password. Even then, someone with access to your .subversion directory
could use that digest to log onto servers listed in your password cache.
My suggestion is to rely on filesystem-level security to protect the
password files. If you want to defend against really stupid attackers
who don't know how to do google searches, promote base64 - this is what
the vast majority of 'encrypted' passwords for network-enabled apps are,
because they still have to 'decrypt' to plaintext. If you cannot rely on
filesystem-level security, don't store passwords to disk.
(Sorry if this came off as a rant, this same thread has come up three
times now this week on different mailing lists I subscribe to. Believe
it or not, I edited this post down... twice.)
-David Waite
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org