11–20 of 41 posts
Earlier quoted context omitted.
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).
Earlier quoted context omitted.
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).
I stopped reading at "Google Authenticator". An app which scan a QR code which contains a clear text key is not enterprise-grade.
Earlier quoted context omitted.
The solution is based on Google Authenticator, which is based on TOTP: 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.
Until you need sudo access to fix ntp
Earlier quoted context omitted.
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.
I stopped reading at "Google Authenticator". An app which scan a QR code which contains a clear text key is not enterprise-grade.
1: https://www.vasco.com/images/DIGIPASS-for-Mobile-ES-201312-v...
Earlier quoted context omitted.
The solution is based on Google Authenticator, which is based on TOTP: 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.
Until you need sudo access to fix ntp
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-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
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
For Debian: 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):
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?
[ed: Looks like it is independent: 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". ]
I stopped reading at "Google Authenticator". An app which scan a QR code which contains a clear text key is not enterprise-grade.
I'll bite... What is your threat model and proposed "enterprise-grade solution"?
Earlier quoted context omitted.
I'll bite... What is your threat model and proposed "enterprise-grade solution"?
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.
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.