A missing piece of the puzzle for me is general OSS tooling to provision the Linux OS users. While it works in some environments to grant multiple parties access to the same underlying OS users, it’s necessary (or at least easier) in others to have users accessed named user accounts.

Step-ca makes good use of NSS/PAM to make this seamless when attached to a smallstep account (which can be backed by an IdP and provisioned through SCIM). While I could stand up LDAP to accommodate this use case, I’d love a lightweight way for a couple of servers to source users directly from the most popular IdP APIs. I get by with a script that syncs a group every N minutes. And while that’s more than sufficient for a couple of these use cases, I’ll own up to wanting the shiny thing and the same elegance of step-ca’s tooling.

Consider the airport attack. Rather than trick me to log with my social credentials, you could prompt me to sign up for a new account on hotspot.xyz. After I enter my email, tell me that the account exists and prompt to log in with passkey.

Now the attacker kicks off the connection targeting my Google credentials. Rather than a fake login screen, they present me with a QR code. From the user perspective, there’s nothing obvious to tell me this is a passkey flow with Google and so I wrongly assume that my passkey must be in my mobile keychain. I scan the QR code and get prompted to approve the login. If I read the block of text on my phone, I will see a mention of the RP (Google.com) but I’d guess most users aren’t looking that closely.

When all is said and done, my hotspot login attempt failed and I’m completely unaware that I just logged into Google on your behalf.

Let’s say that you rely on the passkey implementation in your password manager and have that installed directly on your laptop. When you hit the legitimate site, your password manager prompts for user verification and to approve the login.

When you hit the phishing site and have the QR code pop up, it’s the first indication that something is wrong but the attacker doesn’t have your session yet. Your laptop is not listening for a BLE connection. That only occurs when you scan the QR from your phone and complete the authentication flow there.

In other words, it’s totally opt-in at log in time to use BLE and protecting yourself just means deciding it’s not a feature you trust. If you still aren’t comfortable though, the next move would probably be to just disable Bluetooth on one side or the other.

I also echo some of the other critiques, which are that passkeys are advertised as phishing resistant and not phishing proof. I do understand that the average user may not grasp the nuance, but you leaned pretty hard into the idea that phishing them should be impossible.

One last recommendation. While I do think this is quite clever and a plausible attack scenario, this relies on the out-of-band authentication scenario. Assuming I’m sitting in the coffee shop or airport and click your link, I’m not going to reach for my phone to scan the QR. I’m going to investigate deeper why the passkey isn’t working directly. If you’re lucky, I’ll assume the site has a bug in passkey authentication and fall back to more phishable creds (if the site has both).

I don’t necessarily think of this as a flaw in your attack, rather that it might muddy the waters for readers that are less familiar and don’t realize that this mode is most commonly used when you are authenticating from a non-default device or made the conscious choice not to use a synced passkey.

I didn’t realize it was command line friendly!

The same posture API can be used to restrict access to devices in your inventory or to set up just-in-time access to a sensitive asset. For the latter, you can use a Slack app provided by Tailscale or integrate with an identity governance workflow to set a posture attribute with a limited TTL. Your tailscale policy just needs to condition the relevant access on the attribute.

My number one concern with Azure is availability of resources. Working within US regions, we've had to shift regions during production rollout because one or more of the resources we needed -- a current gen Azure SQL database or App Service Plan -- were simply not available. Rolling out an inexpensive VM (think equivalent of a t3/t4g.micro) is always a ride too, between unavailable SKUs or excessive quota gatekeeping.

Spending gotchas exist on any cloud, but we also know someone who got caught off guard in a completely new way recently. In late-December, the team needed to automate a database event once per day on an Azure SQL instance. Scheduled jobs aren't natively available inside Azure SQL, and so they reached for an elastic job agent. Everything went smoothly until someone dug in to a price increase on the January bill and asked why Sentinel had jumped from under $200 to over $3,000.

A colleague and I helped them dig in and quickly discovered that the controller for the elastic job agent is running dozens of batches per second in order to schedule that one job per day. With default security audit settings on Sentinel to meet compliance obligations, this generates over 600GB of BATCH_COMPLETE log messages per month at a cost of $5/GB for ingest!

I wholeheartedly agree with the recommendation to add a confirmation to the action.

On Linux, ebpf provides an alternative, and I assume, plenty of advantages over trying to maintain kernel level extensions.

I haven’t researched, but my guess is that Microsoft hasn’t produced a suitable alternative for Windows security vendors.

Google has been a big proponent of FIDO, having been an early adopter of U2F in Chrome and leveraging it for advanced protection. More recently, they have extended Chrome support to FIDO2/passkeys and made this move to make it the favored means of authentication for Google accounts.

Given that strategy, it’s a bit of a head scratcher to see Android lagging behind its desktop and mobile competitors. Why stick your mobile customers with second class support for the passwordless technologies you’re pushing everywhere else?!

1. Advanced protection doesn't yet support passkeys. You must keep U2F in place for now. 2. If you have a U2F key configured on your account, Google will prompt you to use it as a passkey before telling you that it's not a passkey and you must login with your password. The net result is that anyone using phishing resistant MFA loses the ability to have their MFA step "remembered" on a device because Google will always prompt for the U2F factor before the password.

This aside, I've been doing a lot of testing with FIDO2 flows using security keys and passkeys across device types and platforms in preparation to roll out passwordless via Okta with a couple of smaller clients. Overall, I love the authentication flow, but there are a lot of gotchas to keep in mind. We've spent a considerable amount of time mapping out the happy path, creating onboarding resources, and documenting business continuity scenarios. The personal use case is actually more of a challenge in some ways, because you need to think about each service rather than just one IdP.

FYI, the easy path right now if you need to support multiple environments is to invest in 1Password or another password manager that supports passkeys. This provides the most consistent user experience and works across most platforms, though we're still having trouble with Android 14.

We're sticking to hardware keys for highly privileged accounts, so admins get a pair of FIDO2 keys. Everyone else gets one Yubikey, which serves as a backup if they lose access to their devices or need to login on an untrusted device. Android is also a problem here. Even in 14, it doesn't seem to support passwordless FIDO2 flows.