On Mon, Jan 26, 2009 at 06:47:31PM +0100, Joop Boonen wrote:
I've checked out ~/.oscrc I saw that my password
can be found in plain text.
This is nothing to be worried about per se -- as *long* as you are aware
of the fact that it is stored there. In general, the home directory
should be well protected also due to other secrets lying around there.
ssh keys, browser passwords and other secrets are often stored on disk,
and often not encrypted or not well encrypted.
As someone who would be able to read this file would
be able to change
packages that I have created. I'm rather worried about it. The package
could easily be piggy backed with mall ware.
I'm wondering wouldn't it be possible to put an encrypted password? Or
even better to work with ssh keys?
An other option would be that the password wouldn't be saved.
Here are some thoughts about this. I try to also cover other
security-related concerns. Sorry about the long mail, but it is a
rather complex topic.
It is planned to check them starting with Python 2.6, which we get with
11.1/SLE11. Earlier Python versions didn't fully support this with the
packaged modules. You can read
for the rationale why
it wasn't too practical so far to add certificate handling with
external Python modules, and why it seemed a better idea to wait until
upstream has solved this (or rather, when the solution becomes available
Regarding password storage:
If you think that passwords stored in another way than plain-text in a
local file are more secure, I don't necessarily agree. Any secret needs
to be stored somewhere, unless you want to enter it everytime you use
it. The various ways to store the secret don't change the fact that it
is stored. In fact, a false sense of security could be inferred.
* Entering the secret every time is of course entirely fine, and albeit
not practical for most people or use cases, requires little more than
hacking the osc configuration parser to not store it to disk. It
should be an easy patch, and I'll happily assist or give advice.
Note that osc also saves a session HTTP cookie that it receives from
the iChain proxy, which is used to considerably speed up the HTTP
traffic; without this cookie, the client has to go through a
painfully slow authentication process for each request that it does.
Hence, it might be desirable to disable storing the cookie, too.
* Storing the secret will almost always mean to put it to disk
somewhere. Whatever kind of secret is used, like cookie, plaintext
password, SSL certificate, the situation is always the same: It
doesn't matter in which form it is put to disk. Encrypted storage
(like encrypted SSL certificate) means that another secret (the
encryption key) needs to be stored or entered every time again, it
doesn't change the situation.
About 5 years ago, when subversion was written, there were endless
threads about this and it was discussed in great depth, how to store
the passwords for HTTP access, whether using agents is feasible, et
cetera. The outcome of these discussions always was that a local file
mode 0600 is about as much as you can do, and it doesn't get any
better from there. (Regarding agent usage, I think that just nobody
bothered enough to implement something.)
It is simply assumed that you have to ensure that the file is
reasonably well protected. This can mean that you symlink the
configuration file to a safe place on your machine (local file
system, root password that is only known by you). It needs to be
treated exactly the same way as ssh private keys. Setting OSC_CONFIG
in the environment should also work.
Note: the client is absolutely required to have access to the
password in clear text, because that's the way that HTTP Basic
Authentication works. (The same is true for Digest Authentication.)
* Storing a base64 encoded password instead of plain text would have
the advantage that in the occasional "looking over someones shoulder"
situation the password cannot be read. That's what CVS did. It would
be fully reasonable to implement this. However, even this can lead to
the belief of false meaning of security. I'd bet that nobody would
ever complain again if we did that - and it would prove my point.
People are shocked when they see their password in plain text, and
that's actually a good thing.
Base64 encoding is no encryption; it is reversible.
The same advantage (protection against haphazardly looking at the
password) is achieved if the password wouldn't be stored inside
.oscrc, but in a separate file, like subversion does it.
* Using a password agent partly improves the situation, but
again it doesn't help against people being root on the local box.
Anyone being root on the local box can get the secret from the agent.
An agent helps to have a file system that doesn't contain a plain
text secret, so if the machine is stolen, it can't be recovered from
disk. Especially with an automatic timeout it could be a viable
compromise, offering some conveniency and some security. Agent
*forwarding* via ssh could be an interesting thing, though. But does
anyone think that ssh-agent (or gpg-agent) can be used to store
opaque data chunks instead of ssh identities? I don't think so. From
cursory look at the code it seems it's built to only work with ssh
keys, which might also be due to the mechanism of key passing.
One thing to consider is that making an agent mandatory would induce
a too large hurdle for most users. Just look at how few people have a
proper ssh agent set up. Many of the build service users wouldn't
bother and simply don't use the build service. But an option for
those people who care makes a lot of sense of course.
I think the two principal options are:
1) HTTPS access + cleartext storage on safe filesystem
2) ssh access with (real) ssh keys
A two-fold approach, as subversion does, offering 1) and 2), seems
best to me.
An ssh-key-based approach should likely be using real ssh and not
trying to re-implement anything. Just like git does.
Alleviating 1) with password managers like Gnome or KDE password
manager would be very good, too.
A problem with the build service password is that it is used for lots of
other things. This makes it much more difficult to keep it secure, and
not spread over all places, and that even though we don't have single
sign-on either. It is unfortunate that the same password needs to be
stored by browsers, scripts, developer's test machines, and other stuff.
There should be separate passwords for some services, really.
"WARNING: This bug is visible to non-employees. Please be respectful!"
SUSE LINUX Products GmbH
Research & Development