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.
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.
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.
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):
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...).
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):
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):
> 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)
And of course the switch statement that handles the core logic starts by checking scratch codes, and if that doesn't work, proceeds to check TOTP/HOTP:
But at least there's a comment documenting the magic return code (#DEFINE VALID_SCRATCH_CODE = 0, or an enum, or basically anything else, anyone?):
/* Checks for possible use of scratch codes. Returns -1 on error, 0 on success,
* and 1, if no scratch code had been entered, and subsequent tests should be
* applied. */
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.
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).
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.
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.
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.
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.
"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". ]
Heh. The "enterprise" solution for this is something like DIGIPASS-ES [1], which is probably TOTP but just broken enough that you have to use their pretty terrible app instead of your existing apps.
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.
That only works for local authentication. Which is fine, the article is about login and sudo.
But there's a problem. If I had partial access and the first factor (password) I'd race the real admin's "sudo" for the U2F touch. Poll list of processes in a loop. If "sudo" was just started, ask for U2F before sudo has a chance. (e.g. by having a pre-started sudo paused in GDB).
U2F has its problems for non-web auth. Just look at how awkward the SSH patches are. (also not secure and/or anonymous (I forget), by the way. See mailing list threads)
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.
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.
Out of curiosity when you say "app" are you talking about the pam module or the phone app? I would agree 2FA shouldn't replace a password but I don't see why it would be an issue as an addition to it.
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.
Totp is a standard protocol.there are multiple f/OS's that do it and are installable from f-droid or buildable and deployable as an apk. The method of getting the app isn't important.
