This discussion kicked off on the wrong list, so since I started
it, I've concatenated the posts.
Intro:
------
I used the --password option in a commit and then found that the
process with my password in full view hung around for an entire week
and could be seen by anyone with access to the same machine by using
ps ef. (no passwords were divulged in the process, but some blushes
occurred)
So, the questions I had were:
* can and should we make svn's --password option a little more secure
against clumsy users than it currently is?
* Is there anything we could do to let svn admins compel users to not
use --password?
* What do we gain by not removing the option of having
passwords in the clear?
Ben suggested that we maybe should add a sentence warning users that
the --password switch is not secure, since I felt that the current
info about it makes it look too 'legit'. ie.:
"(this usually is not secure)"
-----------------------------------------------------
Julian Foad wrote:
Gabriela does make some good points. I think it *is* a good idea to
annotate the --password option as Ben suggested, as the first and
simplest response, but we should *also* consider doing more. Merely
providing an option prominently is implicitly promoting it. We should
reconsider how we expose and document it, and even whether we should
still be providing this option at all -- do we know of better best
practices now?
------------------------------------------------------
This is a summary of Ben's reply:
Ben Reser wrote on Thu, Jul 03, 2014 at 12:54:58 -0700:
> There are only two options to resolve this in my opinion (ignoring the
simple
> documentation solution):
> 1) Remove the option.
> I don't think this is particularly desirable. We use it in our test
suite in
> order to test without having to drive the password prompting.I've used it
in
> examples when showing people how to setup authentication when I wanted
which
> user I was using to always be explicit but didn't want to type a password
all
> the time. Other people are surely using it for automation in places where
they
> aren't concerned about the password leaking via the command line and it's
more
> convenient than seeding the auth cache or driving the password prompts
with
> something like expect. Removing the option certainly creates problems
for us
> as a project with testing and almost certainly causes problems for our
users.
> 2) Redact the password in the argv after starting up and finding the bits
to
> redact.
> I have mixed feelings on this one. I'm not entirely sure that all kernels
> respect this, I know it works on Linux and OS X. But even if we presume
that
> it works on every system where this is an issue, then all it really does
is
> narrow the window in which the password is exposed.If a user is routinely
> using svn with --password and someone sees the redacted password all they
have
> to do is search for newly made svn processes and race our command line
parser
> to retrieve the password before it gets redacted. So in the end we add
some
> more complexity to our command line tools and users are slightly safer but
> they're still not really safe. On one hand this helps users in situations
> where they are not actively being attacked but the password is just
> accidentally observed by someone. But it does nothing to help users who
are
> being actively attacked trying to recover their password.In fact I'd say
it
> creates a false perception of security because the risk would be obscured
from
> the user.
---------------------------------------
Danielsh wrote:
Ben Reser wrote on Thu, Jul 03, 2014 at 12:54:58 -0700:
> 2) Redact the password in the argv after starting up and finding the bits
to
> redact.
>
> I have mixed feelings on this one. I'm not entirely sure that all kernels
> respect this, I know it works on Linux and OS X. But even if we presume
that
> it works on every system where this is an issue, then all it really does
is
It doesn't need to work on "every" system.It just needs to work on
_some_ systems; it'd be fine for it to be a noop on other systems.
> narrow the window in which the password is exposed. If a user is
routinely
> using svn with --password and someone sees the redacted password all they
have
> to do is search for newly made svn processes and race our command line
parser
> to retrieve the password before it gets redacted. So in the end we add
some
> more complexity to our command line tools and users are slightly safer but
> they're still not really safe. On one hand this helps users in situations
> where they are not actively being attacked but the password is just
> accidentally observed by someone. But it does nothing to help users who
are
> being actively attacked trying to recover their password. In fact I'd
say it
> creates a false perception of security because the risk would be obscured
from
> the user.
Note there is a middle way here: we could partially redact the password,
e.g., replace `password` by `password[:3]` or by `random.choice(password)`).
I'm not sure whether it's a good idea (your point about a false
perception of security by uneducated users remains applicable),
-----------------------------------------
Ben wrote in his answer to daniesh:
On 7/3/14 3:09 PM, Daniel Shahaf wrote:
> Note there is a middle way here: we could partially redact the password,
> e.g., replace `password` by `password[:3]` or by
`random.choice(password)`).
Right, I realized there are all sorts of things we can do with respect to
redacting the password to deal with the length issue. Like I mentioned
what I
posted was a very simplistic implementation. Another alternative would be
to
simply set all the bytes in the string to '\0' for both the '--password'
argument and the password itself. Thus effectively removing it from the
output, though I suspect that would leave telling extra spaces in the ps
output.
--------------------------------------------
Danielsh wrote in reply:
> Ben wrote:
> Right, I realized there are all sorts of things we can do with respect to
> redacting the password to deal with the length issue. Like I mentioned
what I
> posted was a very simplistic implementation. Another alternative would
be to
> simply set all the bytes in the string to '\0' for both the '--password'
> argument and the password itself. Thus effectively removing it from the
> output, though I suspect that would leave telling extra spaces in the ps
output.
>
In other words, we'd leak "the user passed the pw via argv" rather than
leak the password itself. We might be able to avoid even that if we
changed the contents of the argv array (e.g., "argv[4] = argv[5];
argv[5] = NULL").
**************************************
To which Ben replied:
On 7/3/14 3:30 PM, Daniel Shahaf wrote:
> In other words, we'd leak "the user passed the pw via argv" rather than
> leak the password itself. We might be able to avoid even that if we
> changed the contents of the argv array (e.g., "argv[4] = argv[5];
> argv[5] = NULL").
Rewriting the array isn't seen by the kernel. At least when I initially
wrote
that example I tried just setting argv[++i] = "<redacted>" and the ps output
didn't change.
Received on 2014-07-04 01:17:41 CEST