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
Received on Fri Sep 19 22:10:46 2003