9 ms·

How to Set Up Two-Factor Authentication for Login and Sudo

139 points by lobo_tuerto 10y ago

Bahamut 10y ago
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.
- deleted 10y ago
  [deleted]
- tshtf 10y ago
  The solution is based on Google Authenticator, which is based on TOTP: https://en.wikipedia.org/wiki/Time-based_One-time_Password_Algorithm https://en.wikipedia.org/wiki/Time-based_One-time_Password_A... The only requirements of TOTP are an accurate time source and keying data for an HMAC. No internet connectivity explicitly required.
  - feld 10y ago
    Until you need sudo access to fix ntp
    - icebraining 10y ago
      You could change the phone's time settings to match the computer's. TOTP doesn't require precise sync anyway, it usually works as long as the two clocks are within 30s of each other.
      - toomuchtodo 10y ago
        If your virtual machine can't sync with an NTP time server for an extended period of time (outbound security group), it will drift beyond 30s from actual time (just saw this in AWS about a year go).
        detaro 10y ago
        AWS instances don't use time from the host by default?!
        dugite-code 10y ago
        Yep, I'm using 2FA with a SSH key on my private web server that's virtualized and regularly have time drift issues. still trying to find a way around it.
        toomuchtodo 10y ago
        Either don't use 2FA or move to physical servers with stable clocks :/
        simonjgreen 10y ago
        apt-get install ntpd
    - theoduino 10y ago
      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.
      - knorker 10y ago
        App also supports HOTP.
      - UnoriginalGuy 10y ago
        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.
    - e12e 10y ago
      From earlier, the google_authenticator pam code/project didn't fill me with confidence, but on the project page it does state it supports "emergency scratch codes" as well as HOTP -- from looking at the code again, I think they are considered the same thing, and it appears if you enter a scratch code, that'll let you log in (and if the code you enter is an invalid scratch code, the system will check to see if it was a valid time-based code): https://github.com/google/google-authenticator/blob/3fb90bdae68f21477b5f97978641497d1048ce37/libpam/src/pam_google_authenticator.c#L1583 https://github.com/google/google-authenticator/blob/3fb90bda... This older article shows a bit of the hoops one could jump through to get a complete system (including the scratch codes etc): https://www.serverstack.com/blog/2013/02/21/implementing-totp-authentication-into-your-infrastructure/ https://www.serverstack.com/blog/2013/02/21/implementing-tot... I've successfully played with the python oath code to get 2fa working with "Star Wars: the Old Republic" (the game has a pretty broken interface for setting up 2fa - to the point that a lot of people give up, even if they give subscribers a 20% monthly bonus in in-game currency for using 2fa...). https://github.com/bdauvergne/python-oath https://github.com/bdauvergne/python-oath Highly recommended for debugging/playing with OATH, in addition to the "main" oath tools, which IMNHO are much better documented (and comes with the binaries needed to do everything, like manually generating codes etc): http://www.nongnu.org/oath-toolkit/pam_oath.html http://www.nongnu.org/oath-toolkit/pam_oath.html For Debian: https://packages.debian.org/jessie/libpam-oath https://packages.debian.org/jessie/libpam-oath See also the always excellent Arch Linux wiki, which adds a tip about generating qr-codes from the secret (so you can store the secret in eg: Google Authenticator easily): https://wiki.archlinux.org/index.php/Pam_oath https://wiki.archlinux.org/index.php/Pam_oath
      - knorker 10y ago
        > it does state it supports "emergency scratch codes" as well as HOTP -- from looking at the code again, I think they are considered the same thing, and it appears if you enter a scratch code No. HOTP and TOTP are treated separately. Both of which are separate from scratch codes. HOTP can't "show the future" (well, you can generate multiple codes but it won't be useful for this) and have an order. Scratch codes are exactly N of them, and they're stored in ~/.google_authenticator and don't have an order. They're also twice as long because unlike the normal codes there's 8 (IIRC) valid ones, and they're ALL valid all the time. (until used)
    - coredog64 10y ago
      We use TOTP for MFA in AWS. Twice now I've had the situation where my token has had the wrong time and the workaround is to enter two successive tokens one minute apart to resync my token with AWS. I didn't RTFA, but I'm assuming it's at least _possible_ to implement an "oh crap!" fallback like this.
z1mm32m4n 10y ago
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 10y ago
  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". ]
matthiasb 10y ago
I stopped reading at "Google Authenticator". An app which scan a QR code which contains a clear text key is not enterprise-grade.
- dfc 10y ago
  I'll bite... What is your threat model and proposed "enterprise-grade solution"?
  - parent5446 10y ago
    I don't agree with the original poster, but to at least supplement: using something like U2F (using pam_u2f) might be more secure, since no secret is transmitted in plaintext, and the secret is usually stored on an untamperable hardware token. Of course, most applications do not require such protection.
    - technofiend 10y ago
      In my limited experience "enterprise" 2FA seems limited to RSA tokens. I'm not sure if I'm 10 years out of date particularly since they were hacked a while back. Wouldn't a more elegant solution be to add Kerberos authentication combined with 2FA? You can then pay the price for access up front but someone phishing your password gets nothing since presumably they cannot answer the second factor challenge.
      - parent5446 10y ago
        Yeah, I mean if the goal is the "enterprise" solution, which is usually the solution where the setup, as well as the risk and damages of a break-in, can be shouldered to another company, then yeah RSA is usually the answer. I was primarily referring to the cryptographic security. Yes, RSA does avoid the transfer of plaintext secrets over the network, but instead you are placing your trust in RSA as a company to not have stored the secrets elsewhere (which, in most cases, is probably just fine). The advantage of U2F is that it uses an asymmetric scheme where a keypair is generated for each authentication endpoint, so the secrets never leave the hardware token in the first place. Compared to RSA SecurID, you would need to have a really severe threat scenario such that you can't even trust RSA with your keys. Of course, U2F is also a much more complicated protocol than say TOTP, and has not existed long enough to stand the cryptographic test of time. To answer your second question, I'm not sure I understand what you mean. TOTP (Google Authenticator), RSA SecurID, and U2F are all different types of 2FA. They could all be combined with Kerberos if that is what you want.
kianga 10y ago
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 10y ago
  I was surprised to discover this!
homero 10y ago
You should use authenticator plus and backup

139 points by lobo_tuerto 10y ago

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.

deleted 10y ago
[deleted]
tshtf 10y ago
The solution is based on Google Authenticator, which is based on TOTP: https://en.wikipedia.org/wiki/Time-based_One-time_Password_Algorithm https://en.wikipedia.org/wiki/Time-based_One-time_Password_A... The only requirements of TOTP are an accurate time source and keying data for an HMAC. No internet connectivity explicitly required.
- feld 10y ago
  Until you need sudo access to fix ntp
  - icebraining 10y ago
    You could change the phone's time settings to match the computer's. TOTP doesn't require precise sync anyway, it usually works as long as the two clocks are within 30s of each other.
    - toomuchtodo 10y ago
      If your virtual machine can't sync with an NTP time server for an extended period of time (outbound security group), it will drift beyond 30s from actual time (just saw this in AWS about a year go).
      - detaro 10y ago
        AWS instances don't use time from the host by default?!
      - dugite-code 10y ago
        Yep, I'm using 2FA with a SSH key on my private web server that's virtualized and regularly have time drift issues. still trying to find a way around it.
        toomuchtodo 10y ago
        Either don't use 2FA or move to physical servers with stable clocks :/
        simonjgreen 10y ago
        apt-get install ntpd
  - theoduino 10y ago
    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.
    - knorker 10y ago
      App also supports HOTP.
    - UnoriginalGuy 10y ago
      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.
  - e12e 10y ago
    From earlier, the google_authenticator pam code/project didn't fill me with confidence, but on the project page it does state it supports "emergency scratch codes" as well as HOTP -- from looking at the code again, I think they are considered the same thing, and it appears if you enter a scratch code, that'll let you log in (and if the code you enter is an invalid scratch code, the system will check to see if it was a valid time-based code): https://github.com/google/google-authenticator/blob/3fb90bdae68f21477b5f97978641497d1048ce37/libpam/src/pam_google_authenticator.c#L1583 https://github.com/google/google-authenticator/blob/3fb90bda... This older article shows a bit of the hoops one could jump through to get a complete system (including the scratch codes etc): https://www.serverstack.com/blog/2013/02/21/implementing-totp-authentication-into-your-infrastructure/ https://www.serverstack.com/blog/2013/02/21/implementing-tot... I've successfully played with the python oath code to get 2fa working with "Star Wars: the Old Republic" (the game has a pretty broken interface for setting up 2fa - to the point that a lot of people give up, even if they give subscribers a 20% monthly bonus in in-game currency for using 2fa...). https://github.com/bdauvergne/python-oath https://github.com/bdauvergne/python-oath Highly recommended for debugging/playing with OATH, in addition to the "main" oath tools, which IMNHO are much better documented (and comes with the binaries needed to do everything, like manually generating codes etc): http://www.nongnu.org/oath-toolkit/pam_oath.html http://www.nongnu.org/oath-toolkit/pam_oath.html For Debian: https://packages.debian.org/jessie/libpam-oath https://packages.debian.org/jessie/libpam-oath See also the always excellent Arch Linux wiki, which adds a tip about generating qr-codes from the secret (so you can store the secret in eg: Google Authenticator easily): https://wiki.archlinux.org/index.php/Pam_oath https://wiki.archlinux.org/index.php/Pam_oath
    - knorker 10y ago
      > it does state it supports "emergency scratch codes" as well as HOTP -- from looking at the code again, I think they are considered the same thing, and it appears if you enter a scratch code No. HOTP and TOTP are treated separately. Both of which are separate from scratch codes. HOTP can't "show the future" (well, you can generate multiple codes but it won't be useful for this) and have an order. Scratch codes are exactly N of them, and they're stored in ~/.google_authenticator and don't have an order. They're also twice as long because unlike the normal codes there's 8 (IIRC) valid ones, and they're ALL valid all the time. (until used)
  - coredog64 10y ago
    We use TOTP for MFA in AWS. Twice now I've had the situation where my token has had the wrong time and the workaround is to enter two successive tokens one minute apart to resync my token with AWS. I didn't RTFA, but I'm assuming it's at least _possible_ to implement an "oh crap!" fallback like this.

z1mm32m4n 10y ago

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 10y ago
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". ]

matthiasb 10y ago

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

dfc 10y ago
I'll bite... What is your threat model and proposed "enterprise-grade solution"?
- parent5446 10y ago
  I don't agree with the original poster, but to at least supplement: using something like U2F (using pam_u2f) might be more secure, since no secret is transmitted in plaintext, and the secret is usually stored on an untamperable hardware token. Of course, most applications do not require such protection.
  - technofiend 10y ago
    In my limited experience "enterprise" 2FA seems limited to RSA tokens. I'm not sure if I'm 10 years out of date particularly since they were hacked a while back. Wouldn't a more elegant solution be to add Kerberos authentication combined with 2FA? You can then pay the price for access up front but someone phishing your password gets nothing since presumably they cannot answer the second factor challenge.
    - parent5446 10y ago
      Yeah, I mean if the goal is the "enterprise" solution, which is usually the solution where the setup, as well as the risk and damages of a break-in, can be shouldered to another company, then yeah RSA is usually the answer. I was primarily referring to the cryptographic security. Yes, RSA does avoid the transfer of plaintext secrets over the network, but instead you are placing your trust in RSA as a company to not have stored the secrets elsewhere (which, in most cases, is probably just fine). The advantage of U2F is that it uses an asymmetric scheme where a keypair is generated for each authentication endpoint, so the secrets never leave the hardware token in the first place. Compared to RSA SecurID, you would need to have a really severe threat scenario such that you can't even trust RSA with your keys. Of course, U2F is also a much more complicated protocol than say TOTP, and has not existed long enough to stand the cryptographic test of time. To answer your second question, I'm not sure I understand what you mean. TOTP (Google Authenticator), RSA SecurID, and U2F are all different types of 2FA. They could all be combined with Kerberos if that is what you want.

kianga 10y ago

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 10y ago
I was surprised to discover this!

homero 10y ago

You should use authenticator plus and backup