
How to Set Up Two-Factor Authentication for Login and Sudo - lobo_tuerto
https://www.linux.com/learn/how-set-2-factor-authentication-login-and-sudo
======
Bahamut
Wouldn't this add a hard dependency to an internet connection? This sounds
like a major drawback in the event of an outage, and would take away a major
feature of most computers.

~~~
tshtf
The solution is based on Google Authenticator, which is based on TOTP:

[https://en.wikipedia.org/wiki/Time-based_One-
time_Password_A...](https://en.wikipedia.org/wiki/Time-based_One-
time_Password_Algorithm)

The only requirements of TOTP are an accurate time source and keying data for
an HMAC. No internet connectivity explicitly required.

~~~
feld
Until you need sudo access to fix ntp

~~~
theoduino
Google Authenticator (I'm not sure about the app, but I know that the PAM
module does) supports HTOP, which is the same HMAC-SHA1-based construction but
relies on a counter instead of the current time. The counter is incremented on
successful password entry (with the PAM module) and on request for the code
via button on the mobile authenticator or token.

~~~
UnoriginalGuy
Which is annoying because now you cannot have an authenticator on multiple
devices. With TOTP as long as you know the secret and time you can spin up
Google Authenticator on anything and it will work, with HOTP you have the
counter synchronization problem. This also makes backups a much MUCH bigger
challenge.

That being said, HOTP is theoretically more secure than TOTP because even if
the secret is exposed (e.g. old backup) they'd still need to crack the
counter. It also does avoid clock problems.

I almost think the ideal solution would be to set up TOTP primarily and HOTP
as a backup. Two different accounts, and you take the HOTP secret (likely QR
code), print it, hide it, and destroy the digital copy.

------
kianga
If the TOTP secret key is stored in the user's home directory, then this only
makes sense for login authentication, but not for sudo: an attacker with
access to the user's terminal can simply replace the secret key and
authenticate against the new one.

~~~
zanchey
I was surprised to discover this!

------
z1mm32m4n
Does this still allow for caching a successful sudo login for a period of
time? Or do you actually have to use a token for every sudo?

~~~
e12e
I seem to recall from testing, that caching of sudo is independent of how you
authenticate -- but it's been so long since I played with it, that I'm not
certain.

[ed: Looks like it is independent:
[https://www.sudo.ws/man/sudoers.man.html](https://www.sudo.ws/man/sudoers.man.html)

"sudoers uses per-user time stamp files for credential caching. Once a user
has been authenticated, a record is written containing the uid that was used
to authenticate, the terminal session ID, and a time stamp (using a monotonic
clock if one is available). The user may then use sudo without a password for
a short period of time (5 minutes unless overridden by the timeout option). By
default, sudoers uses a separate record for each tty, which means that a
user's login sessions are authenticated separately. The tty_tickets option can
be disabled to force the use of a single time stamp for all of a user's
sessions."

Note that the text uses "password", but I think it means "successfully
authenticate". ]

------
homero
You should use authenticator plus and backup

------
matthiasb
I stopped reading at "Google Authenticator". An app which scan a QR code which
contains a clear text key is not enterprise-grade.

~~~
vacri
The very first step, "open google play and install something from it",
indicates that the target audience is not enterprise.

~~~
matthiasb
I made the same comment and I got downvoted as well. I don't vacri is saying
it is bad to get the app from the Google App store. What is not enterprise
ready is the Google Authenticator app itself. I use Google Authenticator for
every consumer application which supports it, but it would be a mistake for an
organization to use it to protect employee access to networks.

