zlacker

>>EthanH+(OP)
This is pretty incredible. These aren't just good practices, they're the fairly bleeding edge best practices.

1. No more SMS and TOTP. FIDO2 tokens only.

2. No more unencrypted network traffic - including DNS, which is such a recent development and they're mandating it. Incredible.

3. Context aware authorization. So not just "can this user access this?" but attestation about device state! That's extremely cutting edge - almost no one does that today.

My hope is that this makes things more accessible. We do all of this today at my company, except where we can't - for example, a lot of our vendors don't offer FIDO2 2FA or webauthn, so we're stuck with TOTP.

>>static+ua
I think 3. is very harmful for actual, real-world use of Free Software. If only specific builds of software that are on a vendor-sanctioned allowlist, governed by the signature of a "trusted" party to grant them entry to said list, can meaningfully access networked services, all those who compile their own artifacts (even from completely identical source code) will be excluded from accessing that remote side/service.

Banks and media corporations are doing it today by requiring a vendor-sanctioned Android build/firmware image, attested and allowlisted by Google's SafetyNet (https://developers.google.com/android/reference/com/google/a...), and it will only get worse from here.

Remote attestation really is killing practical software freedom.

>>c0l0+IH
Let's note that this very concerning problem is only one if organizations take an allowlist approach to this "context aware authorization" requirement.

Detecting changes — and enforcing escalation in that case — can be enough, e.g. "You always uses Safari on macOS to connect to this restricted service, but now you are using Edge on Windows? Weird. Let's send an email to a relevant person / ask for a MFA confirmation or whatever."

>>Signez+rI
Somebody made the front page here a few days ago because they were locked out of Google with no recourse from precisely that kind of check.

>>hansvm+3v1
It wasn't I, but this has been an absolute plague on an organization I work with. There are only 3 people, and we all have need to access some accounts but they are personal accounts. Also, the boss travels a lot, often to international destinations. Every time he flies I can almost guarantee we'll face some new nightmare. The worst is "we noticed something is a tiny bit different with you but we won't tell you what it is. We've emailed you a code to the email account that you are also locked out of because something is a tiny bit different with you. Also we're putting a flag on your account so it raises holy hell the next 36 times you log in."

>>freedo+gH1
Three people sharing a personal account, with one of them frequently traveling internationally, is such an unusual usage pattern that I'd be really disappointed with a service provider if they _didn't_ flag it for extra verification.

>>sciuru+t02
The frustrating thing to me is that as a user they don't give us any tools to help ourselves. I would gladly make it a "team" account and login individually if we could. I would gladly do a shared TOTP, or whitelist login locations, or anything like that. Or at least give us the option to accept the risk and disable whatever anomaly detection they are applying. But no, that's not how the software world works anymore. Extreme paternalism mode is the only option as a user.

>>freedo+r22
Why don't you share a TOTP between all of you? Just take a screenshot of the authenticator QR code, or save it to a shared 1password secret.

Google's login protection mechanisms seem to be satisfied by TOTP usage, and you won't be locked out anymore (or at least much less likely to be).

>>blackr+at2
You're right that would totally work with Google. In our case the boss is quite computer illiterate and trying to get him to use LastPass was hard enough. He will tolerate a lot of pain from getting locked out before he'll be willing to learn TOTP :-(

And for many of the SaaS that we use, TOTP doesn't help you avoid the security lock outs.