Securedrop: Rethink use of 2FA for tty logins

[conorsch]

Requiring 2FA for tty logins is of questionable benefit from a security standpoint: anyone with physical access can boot into single-user mode and gain elevated privileges. Therefore it's probably wise to cease recommending use of 2FA to protect tty logins when physically present with the SecureDrop servers.

See related discussion in:

• #1219
• #1237

[psivesely]

Carrying over from #826 I'm not sure why these issues are being consolidated...

Recent discussion has called into question the value of the 2FA at all, given that physical access can be leveraged to log in via single-user mode, bypassing any 2FA protections on TTY logins. --@conorsch

Why are we equating physical access to the admin workstation w/ physical access to the app server? If decrypted access (Tails volume was obtained while in use or decryption password was seperately obtained) to the admin tails volume is somehow obtained, 2FA has the potential to prevent the adversary from using SSH access to backdoor the app and mon servers. There are many real world situations I can see this being useful in since people tend to take their keyring/ cell phone everywhere and conversely often leave their workstation unattended.

Further, if someone has physical access to the app/mon servers, we don't even use LUKS, so they can directly scoop up what data they want and even plant a backdoor. No need for single-user mode. I think physical access to the app/mon servers already is and should remain outside of our threat model (which I think needs to be re-worked, but that's another issue). When it comes to either the app server or svs--the machines that touch plaintext--physical access should be considered game over™. 2FA TTY login seems like pure theatre.

At the moment, there are two ways to authenticate over SSH:

1. Password + Two-factor (Google Authenticator)
2. SSH keyfiles
   See the discussion in #656 for context.

We should ideally pick one to simplify the documentation and help installers avoid potential mistakes. SSH keyfiles are considered more secure than passwords (although they are probably about equivalent with the addition of two-factor).

It's also possible to use SSH keyfiles with two-factor auth as of relatively recent versions of SSH (6.2, see https://wiki.archlinux.org/index.php/SSH_Keys#Two-factor_authentication_and_public_keys). We should evaluate the security/usability tradeoff here, and consider recommending it. --@garretr

\

Additionally, the SSH passphrase is of questionable benefit, given that the SSH key itself is protected via the LUKS FDE of Tails persistence, and is further compartmentalized from the admin's normal workstation. --@conorsch

I'm very much in favor of just using 2FA with no password or keyfile. Since we're accessing an ATHS, the auth-cookie serves as our first factor (the Tails decryption volume is the "something you know"--which in turn decrypts the auth-cookie value in torrc on disk--and the phone/Yubikey is the "something you have").

[garrettr]

Depending on your threat model, we already have two factor authentication to gain access to the Admin Workstation (and through it, SSH access to the SecureDrop servers):

1. The encrypted Admin Workstation Tails USB, which contains two credentials needed to access the servers: (something you have)
   
   
   
   1. The HidServAuth cookies
   
   
   2. The SSH private key
   
   
2. The password to decrypt the encrypted Admin Workstation persistence (something you know)

If decrypted access (Tails volume was obtained while in use or decryption password was separately obtained) to the admin tails volume is somehow obtained, 2FA has the potential to prevent the adversary from using SSH access to backdoor the app and mon servers.

Here, you are extending the threat model to include an adversary that has access to a decrypted, running instance of an Admin Workstation. Some examples of such an adversary:

• A person who sits down at the Admin Workstation when the actual admin steps out of the room
• Malware on the Admin Workstation

You then argue that we should implement multi-factor authentication such that even an adversary with access to the unlocked Admin Workstation should be unable to connect to the servers at will. You suggest:

There are many real world situations I can see this being useful in since people tend to take their keyring/ cell phone everywhere and conversely often leave their workstation unattended.

Implying that an additional "something you have" factor (e.g. smart phone TOTP/HOTP app, Yubikey, etc.) would be a useful protection against the adversary we just modeled.

I think that there _are_ scenarios where this additional protection could prevent the adversary from logging in to the servers; however, all the ones that I can think of are extremely contrived. Mostly, it would help in the case where an admin leaves the Admin Workstation unlocked (but has no open ssh sessions to either of the servers), and takes their additional second factor (phone or Yubikey) with them (because nobody ever leaves their phone or keys on the table for a few minutes).

In the case of malware, an additional authentication factor would not help at all. The malware could simply wait until the next time the Admin logs in to the servers, then leverage that to gain access. Therefore, I think that an additional layer of two-factor authentication is just security theater, for both SSH and TTY login.

Meanwhile, this proposal would create an additional burden for admins to perform maintenance work on SecureDrop. They now need an additional factor, need to back it up, need to not lose it, need to keep it with them, and need to repeatedly use it to additionally authenticate on top of all the other stuff we ask them to do. Discouraging admins from performing maintenance is a net negative for security in the long run.

[garrettr]

I also think there might be issues with Ansible and SSH where additional layers of authentication are required, but I can't quite recall the details. @conorsch Do you know?

[garrettr]

When it comes to either the app server or svs--the machines that touch plaintext--physical access should be considered game over™. 2FA TTY login seems like pure theatre.

Totally agree. To understand why it exists at all, you should know that we initially required two-factor authentication (password + TOTP) for _both_ TTY and SSH login to the servers. When we switched to Ansible for deployment, which is based on SSH, we had issues with SSH multifactor authentication (IIRC, I'm a little fuzzy on this), so we replaced password + TOTP with public key authentication for SSH. Since TTY login is so rarely used, it was overlooked and not changed at the same time, although it probably should have been.

TTY login still needs further consideration. It currently requires a password (that's the default on Linux, you log in with a username and password), but that password is only used to set up SSH public key authentication to prepare for installing SecureDrop with Ansible. Since this password is basically only used once during installation, it is easy to lose track of it and that sometimes happens. When it does, and something has gone wrong with SSH connectivity, you need physical access to the servers so you can boot into single user mode and recover the system. This would be best be analyzed in a separate issue.

[conorsch]

Great summary, @garrettr. Regarding Ansible support for 2FA, support is lackluster at best. There's no support for PAM integration with YubiKeys for sudo (https://github.com/ansible/ansible/issues/3969) to date, and 2FA with Google Authenticator specifically has gone unimplemented for over a year (https://github.com/ansible/ansible/issues/10065). If there have been recent advancements in either of these areas, I'm not aware of them.

We're already forcing Admins to compartmentalize the SecureDrop credentials from their everyday workstations by using Tails, which goes a long way in reducing attack surface.

I'm very much in favor of just using 2FA with no password or keyfile.

Unfortunately that's nontrivial given the state of the ecosystem right now. In the specific context of the SecureDrop use case, I suggest we keep an eye on discussion surrounding 2FA solutions with config management, and meanwhile focus our engineering resources on streamlining the overall workflow for SD users.

[garrettr]

If you're concerned about the risk of an admin leaving the Admin Workstation unattended, I think we should just add a cautionary note to the documentation reminding them that when they are logged into the Admin Workstation it has full access to their SecureDrop, so they should limit their activities on that machine to only administering SecureDrop, and should not leave the running machine unattended.

[psivesely]

Depending on your threat model, we already have two factor authentication to gain access to the Admin Workstation (and through it, SSH access to the SecureDrop servers):

1. The encrypted Admin Workstation Tails USB, which contains two credentials needed to access the servers: (something you have)
   
   
   
   1. The HidServAuth cookies
   
   
   2. The SSH private key
   
   
2. The password to decrypt the encrypted Admin Workstation persistence (something you know)

By this logic the fact I have my own computer on which I use FDE and store passwords in KeePassX (even in plaintext would be fine by this reasoning though) gives me 2FA to every site I use. I don't think you would agree that's true.

I think that there are scenarios where this additional protection could prevent the adversary from logging in to the servers; however, all the ones that I can think of are extremely contrived. Mostly, it would help in the case where an admin leaves the Admin Workstation unlocked (but has no open ssh sessions to either of the servers), and takes their additional second factor (phone or Yubikey) with them (because nobody ever leaves their phone or keys on the table for a few minutes).

They would also have to know the Yubikey pin or be able to unlock/decrypt the phone.

Meanwhile, this proposal would create an additional burden for admins to perform maintenance work on SecureDrop. They now need an additional factor, need to back it up, need to not lose it, need to keep it with them, and need to repeatedly use it to additionally authenticate on top of all the other stuff we ask them to do. Discouraging admins from performing maintenance is a net negative for security in the long run.

I think we should put our focus on reducing the need for admins to do maintenance (of which we are already aware of many areas we can make significant improvements) more than reducing the time of the authentication process itself to do this maintenance. I think the physical security provided by 2FA is non-trivial and worth supporting _if/when we are able_ (this of course being highly dependent on Ansible support). If it is not worth the time or effort _right now_, we should support it when the conditions are more amenable to doing so.

Use of 2FA is increasingly becoming common, even for things like Twitter, Github, and Gmail, so people are already dealing with the process of "needing an additional factor, needing to back it up, needing to not lose it, needing to keep it with them."

Regarding Ansible support for 2FA, support is lackluster at best. There's no support for PAM integration with YubiKeys for sudo (https://github.com/ansible/ansible/issues/3969) to date, and 2FA with Google Authenticator specifically has gone unimplemented for over a year (https://github.com/ansible/ansible/issues/10065). If there have been recent advancements in either of these areas, I'm not aware of them.

Why not just use an auth PGP key on the Yubikey?

[tomlowenthal]

Isn't it going to be a lot of work to get SSH to work with a Yubikey on Tails? Won't a bunch of that config have to happen every time the Admin Workstation is booted?

[conorsch]

Why not just use an auth PGP key on the Yubikey?

Surely you jest! I've yet to see a decent workflow with GPG auth tokens on a Yubikey in conjunction with Ansible over SSH. From shoulder surfing a few individuals who have attempted a similar setup, I've observed that it's fraught with frustration—and that's even on an everyday, non-Tails workstation, that's infinitely configurable and a more traditional concept of "persistence" than Tails.

Isn't it going to be a lot of work to get SSH to work with a Yubikey on Tails? Won't a bunch of that config have to happen every time the Admin Workstation is booted?

And that's the crux of the problem right there. At the very least, you'd have to configure custom udev rules to grant access to the Yubikey, as well as install the scdaemon and related packages via apt, on every boot. Tails offers persistence for GPG keys out of the box, but kludging together additional persistence is asking for trouble. We're already shoehorning a good deal of custom state for the ATHS values, and that config story has proven exceptionally difficult to test reliably.

[psivesely]

Isn't it going to be a lot of work to get SSH to work with a Yubikey on Tails? Won't a bunch of that config have to happen every time the Admin Workstation is booted?

There's nothing theoretically preventing that work from being mostly automated and made easy for admins, but basing on

We're already shoehorning a good deal of custom state for the ATHS values, and that config story has proven exceptionally difficult to test reliably.

and differences in Yubikey versions/firmwares we'd have to support, it's almost certainly a no-go.

_It was just a thought_ he said.

[garrettr]

By this logic the fact I have my own computer on which I use FDE and store passwords in KeePassX (even in plaintext would be fine by this reasoning though) gives me 2FA to every site I use. I don't think you would agree that's true.

This is a facile comparison. A resource protected by a password only (most of the stuff in your KeePassX database) has different security properties from a resource protected by cryptographic authentication (the SSH public key authentication used to access the SecureDrop servers). Passwords are more at risk because they transit the network and are known to the endpoint server; they are also typically cryptographically weak and reused across multiple sites. Therefore, it is beneficial to bolster their security with multifactor authentication. I do not think multifactor is nearly as beneficial for correspondingly stronger methods of authentication, such as public-key authentication.

I think there are some fundamentally flawed assumptions being used in this conversation: for example, "two factor authentication is always an improvement to the security of a system". Egor Homakov's recent blog post (and the comments on it) are excellent food for thought regarding this assumption.

Again, you need to threat model. If you can demonstrate to me a realistic scenario where two-factor authentication for SSH in the context of SecureDrop improves security in a way that is worthwhile despite the usability tradeoff, I'm all ears. Otherwise, I remain unconvinced.

I still think malware is the biggest threat to the Admin Workstation, and all of the currently proposed solutions for two-factor authentication are helpless in the context of malware. At best, they might delay an attack by hours or days (until the time of the next SSH login). This does not seem like an especially useful property, especially on a machine that is dedicated primarily to logging in to a set of sensitive servers over SSH.

Imagine an attacker who wants to access a SecureDrop server. They cannot do so remotely because they do not have the HidServAuth cookie or the SSH private key. These authentication factors are cryptographically strong and not reused, so they cannot conceivably be brute-forced or obtained from another source. The only way to access it is with data from the Admin Workstation - a compartmented system that is rarely online. The attacker needs to obtain the Tails USB with the actual keys (something you have), and needs the password (something you know) to decrypt them.

It is still possible to attack the system with malware (imagine serving a Tor Browser exploit from a compromised ReadTheDocs for https://docs.securedrop.org), but at that point you need to be thinking holistically about protecting against malware, which is a very difficult problem. I would probably start by hardening likely vectors of attack, then look at hardening the whole system.

Many additional GitHub issues could be filed from the discussion in this thread 😁. However, I encourage you to think holistically as much as possible. There is only so much that can be done incrementally within the current architecture. I think at this point it is more worthwhile to devote that thought to a new and improved architecture rather than trying to monkeypatch the old one.

Finally, there are no right or wrong answers here. Threat modeling and security analysis are complicated and there is room for disagreement. I hope I have argued my point well! I think it is important to remember that even "established wisdom" in the infosec community is often cargo cult, every problem is different, and piling on additional layers of "security stuff" like 2FA doesn't necessarily make a system more secure.

[psivesely]

To recap:

• We're investigating a re-design of the AW/JW/SVS, so it's probably not worth it to invest a lot of time into high-cost, low-benefit improvements of the current model.
• There seems to be no reasonable way to make 2FA work with Ansible + SSH.
• The case in which 2FA SSH would help is narrow, even if we could get it working.
  
  
  
  • Namely, it helps in the case that either the decryption passphrase is filmed or found, or the computer is seized/accessed while on. Then another factor not on the machine--either in memory (e.g., a passphrase or Yubikey pin code) or on person (e.g., phone, Yubikey) would prevent SSH access. It's difficult to make assertions about exactly how likely these situations are, but we can at least agree there are a number of attack vectors we should be paying attention to first.
  
  
• There's no point to 2FA for TTY access.

I'm in favor of just going with keyfiles for ease & simplicity (incl. ability to automate keygen with Ansible, and that Tails has built-in persistence for SSH keys) as well as the fact we've established 2FA would be a potentially very difficult thing to implement (esp. for Ansible) and maintain stability for all for questionable security gain. It seems like everyone is on the same page as far as this goes and we can probably close this issue and maybe open a couple new ones for actually implementing this + removing 2FA TTY.

While we're at it, I noticed that we're still installing libpam-google-authenticator in .../restrict_direct_access_{app,mon}/tasks/ssh.yml. Seems like this is legacy code (last modified Oct 2014) since we're not supporting/ lack instructions for SSH 2FA, but before we just remove it we need to make sure it won't lock any admins out who may have found the support and started using it on their own or otherwise break things. But this is a separate issue.

I still think malware is the biggest threat

Definitely, and where our main focus should be. Though this too is something we can/should begin to consider from a physical (i.e., USB device, other peripherals) standpoint as well in the model where our system can take advantage of VT-D.

[AquaL1te]

Sorry to drop in, I found this thread while searching for a way to secure my TTY's with U2F.

Requiring 2FA for tty logins is of questionable benefit from a security standpoint: anyone with physical access can boot into single-user mode and gain elevated privileges.

That is quite a narrow way to look at it. My laptop has full-disk encryption so booting into single-user mode is not happening. I enabled U2F for GDM, why? Because all my active logins are accessible from my user session. If my TTY's are not protected and a person somehow knows my password then a login from a root TTY is all that person needs to remove the PAM entries and have full access.

So yes, TTY needs to be protected, leaving it would render U2F protection useless (of course in my case with a laptop).

PS: Please spare me the "don't leave your laptop unattended" talk, if that argument is so valid, why use a login password in the first place...

[heartsucker]

then a login from a root TTY

@AquaL1te I think the idea was that if someone has physical access to the app/mon servers and knows the root password, you are so far down into "totally screwed" that adding 2FA to the TTY session is of zero benefit. Not to mention that they could just pop the drive out and mount it on another device. The app/mon server don't have FDE because they have to reboot periodically, and requiring an admin to always wake up at zero-dark-thirty in the morning to turn them on is going to mean a) disabling updates or b) massive downtimes.

As for 2FA for SSH, well, see above.

[eloquence]

The clear consensus here is to remove 2FA (obviously in a carefully staged manner) for TTY logins; opening a new issue just for that and closing this discussion.

[AquaL1te]

I don't really know your whole system setup, but can a user switch to an available tty with e.g. openvt? If so then not only root but other user logins can be attempted without 2FA. The whole point it to have something you know and something you have. The weakest link in that security chain defines your security as a whole. But again, I don't know how your system is setup and all. Just my 2 cents.