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.
I'm not sure I understand what you mean here with:
> I’m not going to reach for my phone to scan the QR
The whole point of the attack is that it can be delivered without you having to scan the QR code, exploiting the fact that browsers allowed (patched) navigation to fido:/ links, initiating the BLE communication to a malicious device that is relaying the communication to the legitimate site, stealing a session. Let me know if that clears up the confusion.
As for phishing resistant/ phishing proof, to some is the same thing, nothing is "anything"-proof so I did not pay too much attention to the wording. Also I just wanted to stress the fact that although some theorized attacks were present, I had not seen anything put in practice before, which is what motivated me to prove it was not impossible.
Thanks for the feedback, will be making changes to the blog to clear up some the the things you have outlined here :)
there are a couple steps before the "1. User scans the QR code" step that readers not embedded in the passkey world might not be familiar with. People who aren't familiar with that flow aren't going to understand the what/why of scanning the qr code to begin with.
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.
