The author's core issue is that once a machine has logged in, it is considered trusted for a period of time. Google should probably make this configurable for particularly security-conscious users (assuming it isn't already), but it strikes me as a perfectly reasonable default.
As with all things security, there are trade offs.
So: 1. Changing recovery emails should require 2FA
2. Changing any 2FA policy should email your recovery email
It does, after all, still require a password. We're really talking about a very, very specific use case where the attacker has a lot of access to an existing session.
I myself have had a phone break and rushed to a computer with a valid session so I could easily reset. It's really a huge UX win, and probably massively reduces 2FA burden/ support burden.
And it does it at unpredictable and often inconvenient times.
The periodic check is undeniably good for security. But google's impl doesn't give the user any indication of when it will happen, and it doesn't allow the user to preemptively re-auth to restart the clock.
This means that I always end up having to re-auth right in the middle of sharing my screen or right when I'm trying to quickly find a thing and in a state of flow.
On good days 1pw is already unlocked and can autofill the login. On bad days I have to manually unlock 1pw and/or hunt for the pw and hope my colleagues don't see my other saved sites and then hope that I don't accidentally paste my password in a doc or something - let alone worry about destroying what was on the clipboard before google decides to do this.
Security and convenience are always at odds, but that doesn't mean you need to give a middle finger to basic UX in the name of security.
AFAICT there are separate clocks for separate high-privileged actions, and some actions require re-authentication every time.
As an example, accessing a saved password on passwords.google.com requires re-authentication for each item you want to access.
It's possible the interface in the chrome native settings or the passwords.google.com interface via chrome on android (which somehow uses native lock screen auth??) are slightly different.
Obviously the backup codes are preferred as you're not storing a master key to all future codes, but it's a lot easier to manage than a second device (at least for me).
Basically everyone else has an "I lost my device" thing and a fallback to SMS codes or email links. This certainly weakens 2FA in general, but strict 2FA is unusable in practice.
Some online storage services have secure areas requiring 2fa to open which would be suitable.
It would also be really bad for usability. Just like it would be bad for usability if you lost access to your Google account forever because you broke your phone.
* Power on laptop, log in using laptop password
* Log in to LastPass, use lastpass password, verify with 2FA. * Connect to VPN, log in using SSO (Okta) password from LastPass, verify with 2FA.
* Open github tab, log in using the Okta password again, verify again with 2FA.
* Open JIRA ticket, get sent to Okta, skips password prompt since already logged in, verify again with 2FA.
* Open email, get sent to Okta, skips password prompt, verify again with 2FA.
* Oh, my calendar tab was already open so Google didn't know I authenticated in another tab so sends me to Okta which now expects another 2FA there once I interact with it.
Also the policy is that the lastpass password, SSO password and laptop password should be different. So that's 3 passwords and 5 2FA pushes in about 5 minutes (and again after lunch as all those sessions expire during it).
My understanding is you can configure Okta to remember 2FA on a device for a while, but our security department has chosen to disable that. This is a lot of security overhead, but in this case I'm being paid for it rather than paying for it so whatever. Can you imagine getting a paying customer to agree to this level of 2FA double checking?
Typical solution: Make the timeout much longer so you don't need to keep doing the work
Correct solution: Deploy a second factor that isn't annoying
If your second factor is a FIDO Security Key then you just touch the key. Doing this a dozen times per day feels about as much trouble as how you have to hit the spacebar to make spaces when typing, ie you aren't even aware of it.
The VPN couldn't easily do this out of the box today (as OpenSSH demonstrates, where there is a will there is a way but I wouldn't trust a typical proprietary VPN client to not open massive security holes this way) but all the web stuff you mentioned could use WebAuthn, and Okta supports that if your employer deployed it as I understand it.
[0]: https://www.macrumors.com/2019/11/12/ios-13-3-fido2-security...
So then you don't need the token because the platform (ie your phone) does the multi-factor authentication itself. In this case you touch a fingerprint reader. I can hold my phone in a way where my right index finger naturally is placed to do this so it feels pretty convenient.
Again, not on iPhones today but it has been demo'd and does already exist on Android.
Actually, that would be very bad for security, because users would work around it. (Well, it might be really, really, good for security if it got people to stop using Google, but I doubt that's what you meant.) As the saying goes:
> Security at the expense of usability comes at the expense of security.
Admittedly if a skilled hacker breaks in into my computer they could recognize what the script does and misuse it. But at least no scripted attack should ever look for it. It's not on github because my seeds are hard-coded and there is not much to generalize.
I use the Yubikey Nano. I have a USB-C version in my laptop and a standard USB version in my desktop PC.
Which, again, is probably reasonable for 99% of cases, but might be undesirable if you're doing investigative journalism on powerful state actors or some such.
> What happens if I lose all of my security keys? > If you still have access to a computer that is signed into your account, you can visit account.google.com and register replacement keys in place of the lost keys.
I don't know of a way, even with full gsuite enterprise policy access, to prevent an attack where the attacker has an active session and your password.
Some things you could do, but would not be full mitigations and likely just annoy an attacker in many cases (though that's often enough):
* via GSuite, enforce 2FA
* Enforce 2FA via hardware tokens/ APP
* Context Aware Access that validates that the login is coming from a specific verified device that is provisioned via your GSuite / conforms to policy, that way the attacker can't just steal the session/password and log in from another device? Maybe?
Really, the attack described requires like 3 different things to go wrong. I agree that there should be changes made to the system to improve this, but it's a rough model to protect a user when the attacker is sitting on the box they're logged into.
As you must assume such a system runs a key logger and will get you password this is a problem. But not a supper big one.
Except if it's a dev-account, because then a lot of things of high importance are linked to it.
I think it's a sane default setup for the causal user. But it and a fiew other defaults should be changed by telling google that this account needs to be secure or similar.
No. No 2FA system is designed to protect you from using a compromised system, as there's no such system possible. No 2FA or any system can protect your account and data from a compromised system. It can make it slightly more difficult, but can not prevent the account take-over.
Even with u2f, if the browser lies to u2f device or to you, all bets are off.
If you value your account, you should not sign into a system you don't have trust.
With googles 2FA implementation they can steal your whole account.
If the compromised system has no way to get your second factor it can't disable/change the second factor methods and can't independently log in.
EDIT:
Sure there are probably many other ways to then trick the user into giving 2FA permission to e.g. change 2FA auth. But this is harder and not always viable in all situations.
I don't think it's unreasonable to expect the attacker to be able to build a little bit of browser automation.
>not always viable in all situations.
Like what?
With WebAuthn / U2F if the browser lies it can result in you authenticating to a different system or under different circumstances than you expected, but nothing else, which seems pretty far from "all bets are off".
In particular a compromised browser could tell you that you're signing into Facebook, when the actual authentication performed is for GitHub, for example.
But because the User Presence detection happens in the physical authenticator it can't fake that, it does need you to press the button, tap the sensor or whatever.
And the credentials obtained this way are inherently one-use, when you take your Security Key away, bad guys can't get any further credentials from the compromised system you stopped using. As we see in this Google example that might not stop them, but that's an application security design issue not an inherent flaw in U2F / WebAuthn.
Sure, there's a user present. That doesn't stop the account being compromised. Users tap that thing all day when prompted. You prompt, they tap, easy as pie.
If you're really advanced you could build a little mechanical arm that would reach out of the computer and tap the key itself.
>And the credentials obtained this way are inherently one-use
That "one-use" could be to add a new 2FA device that's under the attacker's permanent control.