freedomofpress / securedrop

GitHub repository for the SecureDrop whistleblower platform. Do not submit tips here!
https://securedrop.org/
Other
3.62k stars 687 forks source link

Consolidate SSH authentication options #826

Closed garrettr closed 8 years ago

garrettr commented 9 years ago

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.

garrettr commented 9 years ago

After some thought, I think SSH keyfiles (something you have) with passphrases (something you know) would provide sufficient security, as they are roughly equivalent to the current password + two-factor option. The usability would be improved (no one can deny that Google Authenticator is a pain to use often).

Additionally, I think that if "something you have" is an encrypted SSH keyfile on an encrypted Tails persistent device, rather than a TOTP secret on an app on a general-purpose mobile phone, that's a security win.

dolanjs commented 9 years ago

Thing to keep in mind is that ssh keyfiles only applies to SSH not console access. Without the OTP option console access (non ssh) would be single factor

conorsch commented 8 years ago

We've added automatic configuration of SSH aliases for the Admin Workstation via #899. 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.

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. In fact, our docs already acknowledge that a passphrase on the SSH key is superfluous:

If you choose to passphrase-protect this key, you must use a strong, diceword-generated, passphrase that you can manually type (as Tails’ pinentry will not allow you to copy and paste a passphrase). It is also acceptable to leave the passphrase blank in this case.

Moving discussion to #1283.