I’ve also run into various capacity issues in each US region I have worked in. East US 2 has been least constrained for me, but I recall that I was still bouncing around between VM instance types to find one that worked last time I deployed fresh.
Definitely interested to kick the tires and compare to some of the other solutions out there. As others mentioned, you lose some benefits of an OIDC-integrated SSH CA, but that’s a reasonable trade off in order to reduce complexity for many use cases.
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.
I’ve played a bit with this, but iirc, I ran into limitations with some of the clients that needed to be supported. But if all you need is OpenSSH, you should be set.
One devious thing about this attack is that the phishing site doesn’t even need to impersonate the site it’s attacking. I have password based logins on hundreds of sites and it’s plausible that I’ll eventually have passkeys on enough sites that I can’t keep track.
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.
You don’t necessarily have to disable anything, but choose not to use the secondary device authentication flow.
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.
Don’t know where I first discovered it, but I have been using ipkitten for years when working with non-tech friends, family, and clients. It seems to help with the intimidation filter of getting into the weeds, so thank you!
The posture implementation is quite easy to work with. There’s a growing list of integrations, and you can also roll your own with the posture API. I’ve used Kolide so far and will be integrating with Kandji on another tailnet. They also have Intune, JAMF, Crowdstrike, and SentinelOne.
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.
I have significantly more experience in AWS, but I've spent equal time building and securing infrastructure in Azure for at least two years now. While AWS is not without it's rough edges, I'd pick it any day.
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!
The flag button sits right in the zone I swipe with my right thumb on mobile. Occasionally I notice and go unflag something. Clicking through this, I found several pages of posts I’ve flagged. I’d guess I’ve done no more than five posts intentionally. The rest were just the big dumb thumbs.
I wholeheartedly agree with the recommendation to add a confirmation to the action.
I’m surprised that the author chose to configure a public OIDC client for this scenario. Part of the benefit of this pattern is that it’s possible to use a confidential client, since the BFF can securely hold the client secret.
They all support OIDC, though in my experience, it’s moderately more clunky to deploy unless a “blessed” integration exists in the app store/directory. Okta provides the best experience of the three. Google Workspace admins have to drop out to Google Cloud to federate an app that’s not in the OIDC store. Entra ID falls somewhere in the middle between the two.
I love to see OIDC gaining traction, though I will say that for setting up any sort of custom workforce federation, the administrative experience for OIDC applications often feels like an afterthought. I haven’t looked at all implementations, but I have recent experience federating SAML and OIDC applications in Okta, Google Workspace, and Entra ID.
Apple deprecated kernel extensions with 10.15 in order to improve reliability and eventually added a requirement that end users must disable SIP in order to install kexts. Security vendors moved to leverage the endpoint security framework and related APIs.
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.
I work with a variety of small companies (5-25 FTEs) that are increasingly facing strict MFA requirements in order to maintain insurance. SSO isn’t an explicit requirement, but there are a myriad of general access requirements that they struggle to follow without some level of centralization via federated identity/SSO.
Windows 10 had the same behavior. MacOS has also done this by default for years now. I don’t say this to excuse the behavior. On the contrary, I’ve seen many a small business owner run afoul of compliance requirements because they aren’t aware of the default behavior. Slurping data to consumer-grade cloud services ought to require informed consent.
I probably could have framed this more clearly. I don’t think my point really supports the lock-in argument.
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?!
I'm surprised that they're moving forward with this already. As of last week, there were still enough rough edges on their implementation that I disabled it for my Workspace tenants. The two most irritating:
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.