Non-interactive way to supply ControlPort password for nyx and tor-prompt is needed

When Tor's ControlPort requires password authentication, nyx and tor-prompt ask it interactively. However, it must be also a way to specify the password in a command line or in config file. Earlier it was possible with arm's option startup.controlPassword, which no longer works with nyx.

Trac:
Username: wagon

added component::archived/nyx owner::atagar priority::medium reporter::wagon resolution::implemented severity::normal status::closed type::enhancement version::tor 0.3.4.8 labels

Trac:
Username: wagon
Type: defect to enhancement

Trac:
Reviewer: atagar to N/A
Cc: atagar to N/A
Component: Applications to Core Tor/Nyx

Trac:
Username: wagon
Keywords: nyx deleted, N/A added

Oh oops. Thanks wagon, this is a good point, I did forget the controller password from the config options. My bad.

From a technical standpoint I'm unsure it's useful, since a persisted config password is effectively cookie authentication. Said another way, in authentication schemes a password is 'something you know' whereas cookie auth is 'something you have'. If you write your password into a text file it's just a poor man's cookie authentication.

That said, this is likely to confuse others too so I should simply add it. Not sure when I'll get around to this (patches welcome), but I'll be sure it's included in the next release.

From a technical standpoint I'm unsure it's useful, since a persisted config password is effectively cookie authentication. Said another way, in authentication schemes a password is 'something you know' whereas cookie auth is 'something you have'. If you write your password into a text file it's just a poor man's cookie authentication. I would say the opposite: cookie authentication is a poor man's password authentication.

When you use cookie file (i.e. socket mechanism of communication between processes):

1. You cannot use standard firewall tools to monitor access to this file and report all unauthenticated access attempts. You cannot later investigate possible incidents and get information: who (user), when (time), and why (malicious or not?) accessed Tor's ControlPort. Strictly speaking, it is still possible to monitor access with some non-standard sophisticated mechanisms, but I consider them to be more hard to learn and use (than firewall).
2. By default (if you don't use ACL) you are restricted to standard UNIX mechanisms of access control for the cookie file. (For example, you cannot make a single file readable for one user group, but writable for another user group.) Though I cannot tell now some good example when this may be needed, potentially it may happen.

Thus, if you have a properly configured firewall, you get very powerful and flexible solution for both the access control and the monitoring.

However, despite you can configure such a firewall for your needs, there is no standard firewall tool for everybody which works out-of-the-box for most configurations. Without such firewall tool the password authentication doesn't give you more than cookie authentication. So, for layman Tor users, cookie authentication (now working in many systems) is a very simple but still sufficiently secure out-of-the-box solution. Using firewall and password authentication you can do the same and much more, but most of people either don't need it or don't have time and knowledge to configure it.

I'll be sure it's included in the next release Good news! Thank you!

Trac:
Username: wagon

I would say the opposite: cookie authentication is a poor man's password authentication.

Your two points are true for ControlSockets, but a ControlPort with cookie authentication shouldn't differ from password authentication in this respect. In either case nyx is 'providing the contents of a file to tor's control port'. The only difference is that with password authetnication its your raw password, with cookie auth it's an autogenerated hash in a file with especially restricted permissions, and with SafeCookie it's a more complicated handshake that prevents replay attacks and such.

Your two points are true for ControlSockets, but a ControlPort with cookie authentication shouldn't differ from password authentication in this respect. In either case nyx is 'providing the contents of a file to tor's control port'. This was mind-blowing! Thank you for your comment. Actually, the situation is non-trivial, but let me start from the beginning.

_The first point_: why I was wrong. Let's look at man torrc:

CookieAuthentication 0|1 If this option is set to 1, allow connections on the control port when the connecting process knows the contents of a file named "control_auth_cookie", which Tor will create in its data directory. This authentication method should only be used on systems with good filesystem security. (Default: 0)

CookieAuthFile Path If set, this option overrides the default location and file name for Tor’s cookie file. (See CookieAuthentication above.)

CookieAuthFileGroupReadable 0|1 If this option is set to 0, don’t allow the filesystem group to read the cookie file. If the option is set to 1, make the cookie file readable by the default GID. [Making the file readable by other groups is not yet implemented; let us know if you need this for some reason.] (Default: 0)

As you can see, man torrc makes a strong impression, that users which use cookie authentication, will always have to use the same CookieAuthFile as Tor uses (located in /var/run/tor by default)! Moreover, not only man page, but also all how-to and implementations (such as Nyx) also use that Tor's CookieAuthFile from that location. Since I thought this restriction exists, I wrote my point 2: we cannot make clever multi-user access to the same file. Only after your comment I understood that any ControlPort user can just copy that file from /var/run/tor to its own directory, which, indeed, makes cookie authentication to be functionally the same as the password authentication.

_The second point_. Nyx doesn't support cookie authentication too! Strictly speaking, it can read cookie file only from standard place in /var/run/tor. I cannot give to nyx some copy of CookieAuthFile (with the same content) located at another place. This has to be implemented in Nyx.

As I understand it, many applications (including Nyx) have to have some access also to other Tor files such as Tor logs and torrc. So, since these applications will access Tor's log and config files anyway, access to Tor's cookie file is nothing exceptional. That's why everywhere it is recommended to include your user to debian-tor group and to not complicate the things. Nevertheless, in some rare secure cases, some applications can be denied access to Tor files (though ControlPort still can be used by them).

_The third point_. We have 3 types of authentication: password, cookie, and safecookie. I'm not an expert, but at first glance, password authentication looks safer than cookie authentication, but weaker than safecookie authentication. Moreover, according to [[https://gitweb.torproject.org/torspec.git/tree/control-spec.txt|specs]], cookie authentication is deprecated:

the COOKIE authentication method has been deprecated and will be removed from Tor before some future version of Tor.

Unfortunately, at the moment Tor doesn't allow us to disable standard cookie authentication (keeping only safecookie). Should we request some option in torrc for this task? Anyway, in future, we will have only safecookie and password authentications.

I tried to understand how to use safecookie, but was unable to figure out where I should take values for the "[variables]" "Tor safe cookie authentication server-to-controller hash" and "Tor safe cookie authentication controller-to-server hash". Google tells that only two opensource applications use safecookie method, and one of them is your Stem. Thanks to your [[https://stem.torproject.org/_modules/stem/connection.html|code]] I have understood the mystery: it is just literally the value of the constant. :)

Taking into account that it is not so well documented, not so many examples in Internet, and deprecation of standard cookie method, I would like to ask you to include safecookie telnet method to [page] too: instead of the words

SAFECOOKIE authentication is a lot more involved, and not something you will want to do by hand (though Stem supports it transparently).

add a command-line how-to:

% CookieString="$(xxd -u -p -c32 < /var/run/tor/control.authcookie)"
% ClientNonce="$(xxd -u -p -l32 -c32 < /dev/urandom)"
% printf '%s\n' "${ClientNonce}"
9C653314CC4CC2C695999CE84EB1B0045E3D59B6AFFE615D624DB4870DD7041E
% telnet 127.0.0.1 9051
Trying 127.0.0.1...
Connected to 127.0.0.1.
Escape character is '^]'.
AUTHCHALLENGE SAFECOOKIE 9C653314CC4CC2C695999CE84EB1B0045E3D59B6AFFE615D624DB4870DD7041E
250 AUTHCHALLENGE SERVERHASH=16274D83FC2240DF9D50D74009D9AE107B77EA317F0034D3638C7942F350D1F9 
                  SERVERNONCE=1C2E73C41FA8537FDD3A59C2ECBE26DFC85E0A05389373AD8C130C0F5795A036
^]
telnet> z

[1]+  Stopped                 telnet 127.0.0.1 9051
% ServerNonce="1C2E73C41FA8537FDD3A59C2ECBE26DFC85E0A05389373AD8C130C0F5795A036"
% printf '%s%s%s\n' "${CookieString}" "${ClientNonce}" "${ServerNonce}" | xxd -r -p \
> | openssl dgst -sha256 -binary -hmac "Tor safe cookie authentication controller-to-server hash" \
> | xxd -p -u -c32
A733E09A65E2A6030BF6710D800370FC3AD28E1D2545E1692D160545D93CEE68
% fg
telnet 127.0.0.1 9051
AUTHENTICATE A733E09A65E2A6030BF6710D800370FC3AD28E1D2545E1692D160545D93CEE68
250 OK
GETINFO version
250-version=0.3.4.9 (git-074ca2e0054fded1)
250 OK
QUIT
250 closing connection
Connection closed by foreign host.

_The fourth point_. Firewall is a more reliable way to control authentication. If loopback interface is properly filtered, only selected user can send packets to 127.0.0.1:9051. In this sense, in secure setting, even completely disabled authentication is not critical.

Trac:
Username: wagon

Nyxrc option for non-interatively authenticating with a password added.

https://gitweb.torproject.org/nyx.git/commit/?id=65e2f7e

Trac:
Status: assigned to closed
Resolution: N/A to implemented

Thanks! This ticket was about both tor-prompt and Nyx. I cannot see what was changed for tor-prompt. I expected some option for tor-prompt listed also in -h help. Do you plan to fix tor-prompt too?

Trac:
Username: wagon

Hi wagon. tor-prompt does not have a configuration file so no, this does not apply to it. Nor do I plan to add a mechanism for the reason mentioned above (ie, non-interactive authentication should be done via cookies).

I added this to Nyx because it is intended for a general audience. tor-prompt by contrast is a narrowly focused tool for developers and power users who can be educated in tor's authentication options.

What type of authentication do you suggest when tor is controlled from another physical or virtual machine? Should user copy a cookie file over network each time tor process is restarted and, hence, its cookie file recreated? Password authentication was a good compromise in such cases. tor-prompt already supports password authentication, but it asks for a password interactively. You could add -p option to get non-interactive passwords, but then password may leak through a list of processes like ps. So, I'm not sure we can resolve it securely without adding configuration file.

Trac:
Username: wagon

Will you add custom path to cookie file?

The second point. Nyx doesn't support cookie authentication too! Strictly speaking, it can read cookie file only from standard place in /var/run/tor. I cannot give to nyx some copy of CookieAuthFile (with the same content) located at another place. This has to be implemented in Nyx.

Trac:
Username: wagon

closed