Hi,
Von: Gabriela Gibson [mailto:gabriela.gibson_at_gmail.com]
> 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)"
[Long discussion snipped to protect the innocent]
As far as I know, an environment variable could be used as an alternative. It can be set by shell scripts and the python test harness locally (only affecting the started svn sub process), and on most operating systems, other non-admin users don't have any ways to read out those.
This should be easier than using a password file.
In addition to the documentation changes, a warning could be issued in runtime when someone uses the --password option, advising them to use the environment variable instead
Best regards
Markus Schaber
CODESYS® a trademark of 3S-Smart Software Solutions GmbH
Inspiring Automation Solutions
________________________________________
3S-Smart Software Solutions GmbH
Dipl.-Inf. Markus Schaber | Product Development Core Technology
Memminger Str. 151 | 87439 Kempten | Germany
Tel. +49-831-54031-979 | Fax +49-831-54031-50
E-Mail: m.schaber_at_codesys.com | Web: codesys.com | CODESYS store: store.codesys.com
CODESYS forum: forum.codesys.com
Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner | Trade register: Kempten HRB 6186 | Tax ID No.: DE 167014915
-----------------------------------------------------
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 11:08:11 CEST