Reading through the Chromium bug report, it looks like the reporter wasn't able to get in contact with Mozilla until February, so after they were aware it only took a month to fix the bug in Firefox. It's unclear when they started trying, and who's fault the delay is.
I can't speak to the prioritization differences between the different browser teams, Chrome was definitely the best which isn't surprising considering their resources. Apple was also quite swift but I imagine it took them some time to decide where to deliver the fix, I myself wasn't sure if this is something that should be blocked at the OS level (the Authentication checking the intent origin) or browser. Mozilla is usually the slowest out of the three but they were still very professional.
The involved engineers are most likely running around with a blushed-red face to this day, claiming "phishing resistance" in all the marketing materials but then having such a bug. I'd say the cover-your-ass (CYA) reflex was a big incentive for google engineers to fix it quickly.
Phishing resistance isn't a binary property, it's a spectrum, and even with this vulnerability, that of passkeys is orders of magnitude higher than that of most other alternatives (including passwords, SMS OTP, TOTP etc.)
This attack requires physical presence and visiting an attacker-controlled page. It’s absolutely a real threat and great work, but there are multiple orders of magnitude more people getting phished using weak MFA than by an attacker with control of a BLE device in their home or office.
I’m missing something. If WebAuthn is “ssh for the web” then why would it matter if Bob was phished and logged into the fake crypto portal running on the raspberry pi? It’s not like the attacker now knows his private key. Is the danger that Bob also would share his crypto wallet keys with the fake site or something?
The attacker has access to whatever the passkey was protecting. It's like asking who cares about password phishing. And FWIW a crypto portal in front of something like Coinbase can obviously do a lot of damage since most people do not keep their crypto in their own personal cold storage.
Attacker is now logged in on the real crypto portal as Bob. SSH equivalent would be like connecting to malicious server with SSH agent forwarding enabled.
I suppose you can completely skip dummy sites when phishing for passkeys since the user doesn't know the password and therefore you don't need him to enter said password anywhere (which is why you needed a dummy site in the first place).
I don't use BLE PassKeys, but wouldn't the user also have to be paired with the attacker controlled BlueTooth device to get the connection request? Does the "The victim’s Authenticator connects to the attacker’s Client" step's authorization include pairing to a new device and not only allow a log-in with an already connected one?
The diagram in the post has the user device talking to the attacker device over Bluetooth, and the bug description explicitly says "An attacker within bluetooth range" - which heavily implies to me your device actually is pairing with the attacker device somehow! If already being paired with the attacker Bluetooth device is a prerequisite for this attack that's much less of a concern imo.
As far as I can tell, no pairing (or indeed any kind of logical Bluetooth connection) is required in the protocol used. The (device containing the) authenticator broadcasts a Bluetooth LE advertisement, and the "client platform" (i.e. usually the browser) has to be able to receive its contents to prove physical proximity.
Such a (by definition unidirectional) Bluetooth LE advertisement can easily be received and relayed over arbitrary distances.
IIRC caBLE ("cloud assisted bluetooth low energy") sidesteps the usual bluetooth pairing process by using out-of-band channels (QR codes, NFC) to exchange initial pairing information.
Sure, if you assume the session is scoped to allow registering a new passkey. Depends on how the application is configured. Regardless, getting the credential is different from getting a session.
Arguably, "phishing a credential" doesn't necessarily have to mean full compromise of the credential itself.
For example, in the case of SMS-OTP, the credential is (access to) the registered phone number, yet I'd still call an attack that successfully intercepts one OTP in time to use it a successful phishing attack.
Author of the blog here, I actually agree with you the subheading is quite misleading, any tips on what would be more appropriate? "Phishing PassKeys sessions using browser intents" doesn't make much sense to me
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.
I only felt the need to leave a grumpy comment because of the word “credential”, so deleting it might help even if it leaves ambiguity. Otherwise maybe something like “attacker in the middle any site’s passkey authentication using browser intents” sounds more accurate.
This would be a nice ublock origin filter for Firefox Android. I installed one that blocks sites requesting localhost addresses, after I noticed some websites portscanning my localhost for "security".
Localhost is typically uniquely trusted, generally speaking, even when loading a localhost page on HTTP it behaves like a page served over HTTPS would (in terms of the browser APIs you have access to for example). Also for a port scan it's not all that unusual since you can do it without loading any resources, so CORS alone wouldn't protect you from it. Maybe an extension that injects / modifies CSP rules could protect from this but it might also end up breaking websites.
That's what I was trying to get at: Are any websites using this legitimately to communicate with local applications? If so, isn't that a pretty big fingerprinting and attack vector (how are websites authenticating themselves to these local applications and vice versa)?
Potentially? Typically nowadays if you have some application on the host and a browser component (like a password manager) you would use a native messaging host and extension. There's also deep links / intents type communication. But if neither of those fit your use case I guess you would be able to have something running on localhost, maybe for something like an FTP server it would be more common. The ports that these scripts typically scan are those of known automation tools as well as malware, example is port 9222 for Chrome Devtools Protocol.
Edit: Also any local network equipment probably uses local ips a lot, they often have web UIs that have legitimate use cases for this.
> Localhost is typically uniquely trusted, generally speaking,
Sure, but that trust is about me, an owner of this particular localhost, interacting with it, not trust some.website.on.web to have an unchecked communication with it.
I should probably have rephrased it a little, I don't disagree with you at all, was just adding more context on localhost and some of the nuances with it when it comes to browser behavior.
For reference, uBO has a filter list called "Block Outsider Intrusion into LAN" which you can enable. That blocks all cross-site requests to local IP addresses, "localhost", and some other well-known locally-resolved hostnames.
Another attack vector is public DNS names that resolve to local IPs as well, like "lvh.me". I block these with a local dnsmasq instance and the "stop-dns-rebind" setting.
Still not sure if this catches everything, probably not. I really wish browsers would just block all of this by default and ask for permission.
> Another attack vector is public DNS names that resolve to local IPs as well, like "lvh.me".
uBO LAN list blocks those as well, only except strict 1st-party connections, i.e if `lvh.me` is used as connections on other domains (including different subdomains), it will be blocked.
This attack is very active, in contrast to Firesheep. The attacker needs somebody physically close to their Bluetooth device to additionally visit a site they control.
Definitely not impossible, but still a very different threat level.
Security engineers aren't infallible. This is a really clever channel confusion attack that presumably just nobody considered. It happens, unfortunately.
Clever attack indeed - wouldn't have expected for this to be possible. I trusted the claims of Webauthn / Passkey being "phishing proof" without much consideration, because these claims came from highly respected companies. Unfortunately this is yet another example for "trust, but verify".
I'm curious if folks tried to use a model checker. Seems like a model checker might be able to identify cases in the spec where invariants are violated.
I don't think that that would have helped here: The invariant ("URLs purportedly resulting from a QR code scan must only result from an actual QR code scan") essentially follows directly from a specific threat scenario that was missed.
Any professional should know this. Claiming any credential scheme is unphishable is not honest. Leading wider marketing with "phishing-resistant" is not far from that, knowing that the subtlety is lost on the public.
Because secure engineering is extremely hard? That's two really quite uncharitable replies from you in this topic now, and IMHO it's really unwarranted. One of the worst smells for secure engineering is the insistence of the people involved that they'd never make a dumb mistake like "that other" group did.
Basically nowhere is humility more of an asset than in this world.
I totally agree with you. That's why claiming your technology is "phishing proof" reflects badly on the people involved who are all supposedly experts in their field, and well-compensated on top.
The protocol is; the implementations weren't, in this case. (To be fair, the specification didn't explicitly say "validate the origin of the pairing secret to actually be a QR code scanner", but that's still more of a missing (important!) implementation warning than a protocol design flaw.)
Compare this with passwords, where the protocol is fundamentally phishable, with partial mitigations requiring user discipline (e.g. only ever using password manager auto-fill) and a lack of local or remote vulnerabilities.
Most claims about Passkeys are "phishing resistant" not "phishing proof". This scenario is still more "resistant" than passwords: it requires a believable MITM proxy for a specific website that is also physically in someone's near-area network/personal-area network to pick up intentionally low powered Bluetooth LTE packets, and to click through a login flow that on most of these OSes/browser combos looks decidedly different ("remote login" instead of "real login"). Obviously that's still a threat model to consider, just as one should generally worry about logging into anything on a public Wifi, but the number of "ingredients" to get right on this phish attack is much higher than anything password related, and is much harder to scale (spearphish) because as amusing as it sounds to try to build a fleet of Raspberry Pis to blanket a public space it starts to get physically impractical.
This is a "I'm going to phish a very specific person's wallet in meatspace" attack, not a "I'm going to remotely phish anyone on the internet's wallet".
(It's also an attack we've already got mitigations rolled out in major browsers and more planned.)
The way things like this are developed is not by "clever and highly paid engineers". They're developed by a cabal of businesses led by a standards body to try and wrangle all the competing interests into one solution for everyone's problems (lol jk, it's to solve the problems of the most influential organizations involved).
Because the whole process is design-by-committee on crack, the solutions don't tend to be technically very good. But they don't need to be, because they're not trying to solve a technical problem, they're trying to solve a business problem.
The solutions they come up with are always ugly and broken at first, and don't account for all the needs of everyone (remember, only the most important's needs get met first), so they eventually churn out a fixed version and that becomes the version everyone ends up using long term.
WebAuthn/Passkeys/FIDO/etc aren't even one solution or standard. They're a cobbled together patchwork of different pre-existing standards with some extra pixie dust mixed in. Almost everyone agrees that the users and implementers are who loses out when these things are pushed. But a couple giant businesses have an easier time solving their problems, which are large-scale security problems. And all the rest of us use it, because we tend to defer to large powerful authority figures, and we don't know what the hell else to do.
Whatever universal solution is pushed will continue to suck balls, because there are too many different use cases, and no single solution will ever work well for all of them.
What has worked, is working, and will continue to work, is to simply support a variety of different security mechanisms independently, and allow users to install a password manager which wrangles it all for them, across different use cases, sites, applications, devices, organizations, etc.
I don't know about today, but in the 1980s, "water resistant" for wristwatches meant that you could wash your car and the hose-spray wouldn't turn it into a brick.
Can today's "water resistant" smartphone be dropped into a swimming pool with no ill effects? I don't know. But "resistance" as a marketing term is often far overblown, even with strict product standards in place, and for cryptography/authentication there is zero consumer protection or transparency.
Any accountability for service providers is usually lip service anyway. Read your software licenses: there are no warranties, for any purpose, ever.
What prevents essentially the same attack from being done by making a (desktop / tablet or even wall-mounted-display) web page that shows a QR code that, when scanned by a victim device, triggers the authentication flow?
Is there some handshake over BLE that allows a browser that speaks BLE and shows a QR code to trigger the FIDO flow but does not allow a QR code by itself to do so? If so, how? Remember, the attacker is presumed to control a BLE device in range of the victim’s authenticator.
Nothing, by definition. If an attacker can successfully proxy all channels designed to frustrate proxying attacks, it's game over, at least without a distance bounding protocol being used (and I don't think Bluetooth has one).
Signal Power affects readable distance (signal to noise radius) and the specs for this do suggest the lowest power Bluetooth LTE packets for the shortest "personal area network" distance we can get for these FIDO requests.
(It doesn't entirely solve it, you can be extremely unlucky with a radio bounce or a surprisingly quiet Bluetooth radio band at transmission time. Surprising because Bluetooth is somewhat intentionally in one of the noisiest radio bands we've allowed to be extremely noisy.)
GP mentioned Bluetooth proxying (i.e. using two devices forwarding protocol messages bidirectionally to create a "Bluetooth wormhole"), which doesn't have any obvious inherent distance bound in this protocol, as as far as I can tell.
Indeed. That attack is a little more involved (requires having a BLE device in proximity and tricking the user into scanning a QR code outside of the normal browser flow), but it seems like the main issue is that there's no way for the authenticator to validate that the device that's actually being authenticated is the device that the user actually intends to authenticate.
That's what the user intends, but there's no way for the authenticator to know whether the QR code it's scanning is actually from a webauth session on the device it's scanned it from, or simply proxied from another device: ultimately the QR code is just a bunch of pixels, and a web page can display arbitrary pixels.
Basically, there would need to be some device-specific private key included in the QR code which the authenticator could check somehow, but that trust needs to be established first somehow
One potential mitigation I could imagine is browsers actively trying to prevent FIDO QR codes from being rendered in web pages, but that's pretty difficult to stop
This is, of course, something that an attentive user can likely detect, as the browser can prevent web pages from mimicking the QR code workflow exactly, but a) webauthn is supposed to prevent this from happening, as the 'line of death' has proven to be a poor barrier, and b) there's no good way for the authenticator scanning the QR code to identify this line of death reliably.
(And, of course, the designers of this interface knew this could be an issue, which is why BLE is involved at all: so that this kind of attack can't just be done entirely remotely. But BLE is a bad way of identifying a particular device compared to, say, plugging in a USB port. Especially also imagine compromised IoT devices...)
At least that much seems reasonable to detect (e.g. by blocking FIDO URLs from being opened in browser, but also by the FIDO URL handler verifying whether the caller is a camera application or a browser).
Yeah, the behaviour which was fixed recently was even worse, but it's still a bit of a concerning feature of a scheme which is supposed to be 'unphishable'
Though mitigations on this are that the QR codes in BLE authentication are inside browser/OS dialogs, not a part of the webpages. Obviously a web page can still put a lot of work into pretending to be browser/OS dialogs, but there are some mitigations in place of "does this look like the right prompt for this style of login?" already. Also, obviously some of that is a training problem of "don't just scan random QR codes, look for the ones specifically framed in browser dialogs" and given how hard it can be in general to train people to be skeptical of random QR codes there will always be human failures in that space.
One of the tricks is going to be avoiding Bluetooth logins in the long run. Microsoft has mentioned interest in finding better ways to better flow keys cross-platform. Also, BLE logins should be rare in general if handled well (BLE login once and only once on a different platform to add a key for that platform directly to the site) and we shouldn't be training users to expect "login via QR code" as the "norm". (Of course, yes, that's also a training situation with a lot of human failure modes.)
What an excellent write up. Adding a Web Bluetooth API to the browser to then be later used for "secure" actions like passkeys or logins never made any sense to begin with.
How much was this bounty if there was any? Looks like a 7.8 severity CVE [0].
This issue is mostly seperate from Web Bluetooth: it'd be an issue even if that API didn't exist at all (though, of course, these APIs make it a little harder to use those interfaces for validating anything, though thankfully not that much harder because it's fairly easy to add some 'hey, this is really a browser and not a web page making this request' signal, as opposed to with QR codes, which are ultimately just a collection of pixels and it's the very-hard-to-evaluate context in which it appears on the device's screen which makes for that seperation.)
If I understand it correctly (I had some trouble wrapping my head around the exact attack vector):
The problem here is that browsers allow redirecting users to the installed passkey implementation/"backend" in the same way that camera and dedicated QR scanner apps legitimately use to initiate cross-device authentication via (what used to be called) caBLE, right?
In other words, the attacker primes the user for an upcoming authentication on-device authentication, but in reality initiates an off-device authentication to their own device.
And the fix is presumably to not accept off-device authentication intents over anything that's not a QR scan, or at least filter them out in the browser?
Correct, the Chrome fix at least was to block fido:/ URL navigation, so the victim can't get redirected to their passkey application with the phished URL.
I think that we can easily say that it is a huge "epic fail" for the whole ecosystem of people that pushed for "Passkey" with the argument that "this was more safe than password that need to be deprecated"...
It's worth keeping in mind that if you enter your password in an attacker-controlled website, you lose your entire credential, not just one malicious authentication/signature using it such as here.
Also, this vulnerability is very patchable; password phishing is incredibly hard to prevent.
Although this is an attack that can be carried out in practice, it is not quite as scalable as phishing passwords of potentially millions of users across the world. Passkeys are still in general more phish-proof than passwords.
How can I disable Passkeys over Bluetooth? Given the severity of vulnerability and the "fix" just plugging one hole of potentially many more, I'd rather have it permanently disabled.
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've had a _really_ good experience with passkeys + 1Password. I vastly prefer it over a password + TOTP 2FA.
It was a little rough at first, but support is pretty good now. The only real concern is I don't know how to export passkeys out of 1Password if that were needed.
This is just one more reason to keep bluetooth disabled on mobile devices. There have been other vulnerabilities with bluetooth itself, and bluetooth is constantly used to track people. What's the point of leaving it on all the time when most of the time it's just going to drain your battery and open you up to being tracked or exploited.
Eventually your usb-c port will get clogged up with pocket lint.
The SIM card extractor that comes with your phone works really well at cleaning it, or you can also use a toothpick to get the lint out, just be gentle so you don't bend stuff inside the port.
How so? Unless you grant Bluetooth permissions to apps (that then start broadcasting identifiers) or explicitly make your device discoverable, this shouldn't really be a thing.
> What's the point of leaving it on all the time when most of the time it's just going to drain your battery and open you up to being tracked or exploited.
Just people with a wearable have at least one Bluetooth device connected to their phone at all times. Bluetooth headphones are also very popular.
We need hardened and privacy-protecting Bluetooth stacks, not blaming people for using their phones as designed and advertised.
Over ten years ago retailers were already tracking customer's cell phones as they walked around the store to see what sections people walked through. Your phone constantly sends radio waves out that are identifiable to the individual device.
In what way is a modern Bluetooth device (let's assume both classic and LE) uniquely identifiable, other than for the caveats mentioned above? 2013 was indeed over a decade ago.
> How so? Unless you grant Bluetooth permissions to apps (that then start broadcasting identifiers) or explicitly make your device discoverable, this shouldn't really be a thing.
> We need hardened and privacy-protecting Bluetooth stacks, not blaming people for using their phones as designed
Phones are explicitly designed to collect and leak as much of your personal data as possible. Nobody us going to implement hardened bluetooth stacks that protect you because that defeats the whole purpose. We're lucky they allow us to disable bluetooth at all. They've already changed airplane mode to continue using wireless and bluetooth even when enabled. Any useful features of bluetooth you might use with your phone is probably just bait to get to leak more of your data. They've removed headphone jacks to force your hand, but most people could at least make sure that bluetooth isn't enabled while it isn't in active use.
I'd agree that sometimes privacy can be orthogonal to the manufacturer's interests, but that sounds like a complete conspiracy theory that doesn't pass Occam's razor.
What benefit would phone manufacturers have from their devices being trackable via Bluetooth, or if it's not themselves, who is paying them for it?
Also, I'd love to see an answer to my original question: How exactly do you track a stock iPhone or Pixel with Bluetooth enabled? Neither transmit a persistent identifier, and none of the technologies linked change anything about that. They require explicit cooperation of an app on the device side, which is gated behind a prompt on both iOS and Android.
Your last link actually suggests the opposite: Bluetooth beacons allow apps to position themselves more accurately indoors and then do with that information whatever they want – if you grant that permission in the first place.
> What benefit would phone manufacturers have from their devices being trackable via Bluetooth
In Google's case, they use bluetooth to track the location of android users and the bluetooth devices near them. In addition to data collection, it helps their "Find my Device" network. I suspect Apple's system also uses bluetooth to identify nearby apple devices and beacons.
Obviously phone manufactures are primarily self-interested, but part of that also means offering extensive data collection opportunities to third parties such as app and accessory developers to attract people to their platform.
> Also, I'd love to see an answer to my original question: How exactly do you track a stock iPhone or Pixel with Bluetooth enabled?
While I don't have a pixel or an iphone, it does appear that there are ways to passively track these devices via bluetooth:
Both Google's and Apple's "Find my" are services implemented on top of Bluetooth which you can disable independently of it. They're basically pre-installed apps (e.g. Tile used to do the same thing using a third party app before them). Including them to support the statement "Bluetooth itself is intentionally used to track users" seems like moving goalposts.
Yes, these services being enabled by default isn't great, but if you're claiming that there's any data collection or intentional device broadcasting happening beyond that, i.e. at the base OS level, I'd be happy to see evidence of that (as I would also find that very concerning).
Regarding antenna/transmission chain/baseband fingerprinting: These are indeed concerning, and I hope there will be countermeasures available at some point. But these should theoretically affect all radio technologies, right? In that case, turning off (just) Bluetooth would not help much, given that phones have at least one other permanently enabled radio. It's a different story for devices that have only Bluetooth, of course.
I don't use bluetooth much and I have no idea what the technical details are, but surely an attacker can find a way to either guess or determine what bluetooth devices your phone is paired to and then pretend to be that device. (like a keyboard)
Also according to my experience there is no "permission for bluetooth", it all falls under "Phone" or whatever other permission on Android.
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.
120 comments
[ 5.1 ms ] story [ 182 ms ] threadSafari: fixed in 18.3 (Jan 2025)
Firefox: fixed in 136 (March 2025)
Chrome: fixed in 130.0.6723.58/.59 (Oct 2024)
Wow - only Google seemed to really prioritize fixing this / had the processes and manpower to get a fix out quickly.
Mozilla’s bug report is still locked down but Google’s is open: https://issues.chromium.org/issues/370482421
I would have guessed they'd be the quickest, but I wouldn't have guessed they'd be months ahead of the others.
but it's not public, perhaps someone can tell us when it was opened.
https://learn.microsoft.com/en-us/deployedge/microsoft-edge-...
https://msrc.microsoft.com/update-guide/en-US/vulnerability/...
Whether that's catastrophic or not will vary case by case and depends on what exactly you're securing with the key.
Such a (by definition unidirectional) Bluetooth LE advertisement can easily be received and relayed over arbitrary distances.
For example, in the case of SMS-OTP, the credential is (access to) the registered phone number, yet I'd still call an attack that successfully intercepts one OTP in time to use it a successful phishing attack.
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 :)
That's what I was trying to get at: Are any websites using this legitimately to communicate with local applications? If so, isn't that a pretty big fingerprinting and attack vector (how are websites authenticating themselves to these local applications and vice versa)?
Edit: Also any local network equipment probably uses local ips a lot, they often have web UIs that have legitimate use cases for this.
Sure, but that trust is about me, an owner of this particular localhost, interacting with it, not trust some.website.on.web to have an unchecked communication with it.
Another attack vector is public DNS names that resolve to local IPs as well, like "lvh.me". I block these with a local dnsmasq instance and the "stop-dns-rebind" setting.
Still not sure if this catches everything, probably not. I really wish browsers would just block all of this by default and ask for permission.
uBO LAN list blocks those as well, only except strict 1st-party connections, i.e if `lvh.me` is used as connections on other domains (including different subdomains), it will be blocked.
Definitely not impossible, but still a very different threat level.
To me it seems that WebauthN/PassKey was a significant project where all of the clever and highly paid engineers from the big corporations took part.
How can they overlook such an attack vector? Especially when the main selling point for the new technology is "resistance against phishing"?
Even MS has in their FAQ: Are "Q: passkeys phishing resistant? A: Yes, passkeys are phishing resistant" [1]
[1] https://support.microsoft.com/en-us/windows/passkeys-frequen...
Because secure engineering is extremely hard? That's two really quite uncharitable replies from you in this topic now, and IMHO it's really unwarranted. One of the worst smells for secure engineering is the insistence of the people involved that they'd never make a dumb mistake like "that other" group did.
Basically nowhere is humility more of an asset than in this world.
Compare this with passwords, where the protocol is fundamentally phishable, with partial mitigations requiring user discipline (e.g. only ever using password manager auto-fill) and a lack of local or remote vulnerabilities.
This is a "I'm going to phish a very specific person's wallet in meatspace" attack, not a "I'm going to remotely phish anyone on the internet's wallet".
(It's also an attack we've already got mitigations rolled out in major browsers and more planned.)
Because the whole process is design-by-committee on crack, the solutions don't tend to be technically very good. But they don't need to be, because they're not trying to solve a technical problem, they're trying to solve a business problem.
The solutions they come up with are always ugly and broken at first, and don't account for all the needs of everyone (remember, only the most important's needs get met first), so they eventually churn out a fixed version and that becomes the version everyone ends up using long term.
WebAuthn/Passkeys/FIDO/etc aren't even one solution or standard. They're a cobbled together patchwork of different pre-existing standards with some extra pixie dust mixed in. Almost everyone agrees that the users and implementers are who loses out when these things are pushed. But a couple giant businesses have an easier time solving their problems, which are large-scale security problems. And all the rest of us use it, because we tend to defer to large powerful authority figures, and we don't know what the hell else to do.
Whatever universal solution is pushed will continue to suck balls, because there are too many different use cases, and no single solution will ever work well for all of them.
What has worked, is working, and will continue to work, is to simply support a variety of different security mechanisms independently, and allow users to install a password manager which wrangles it all for them, across different use cases, sites, applications, devices, organizations, etc.
> Passkeys are like digital keys ...
But Joe User doesn't yet know what a "digital key" is, not yet anyway, so this is at best a forward reference.
> The public key is registered with the website or application.
Joe has no idea what "registered" means in this context.
The passkey is being compared to a digital version of a physical key, the brass object used to unlock doors.
Phishing resistant is different than phishing proof.
Passkeys remain phishing resistant, even in light of such an attack.
Can today's "water resistant" smartphone be dropped into a swimming pool with no ill effects? I don't know. But "resistance" as a marketing term is often far overblown, even with strict product standards in place, and for cryptography/authentication there is zero consumer protection or transparency.
Any accountability for service providers is usually lip service anyway. Read your software licenses: there are no warranties, for any purpose, ever.
https://chromium-review.googlesource.com/c/chromium/src/+/59...
Edit: QR code scans are actually allowed to open such links.
(It doesn't entirely solve it, you can be extremely unlucky with a radio bounce or a surprisingly quiet Bluetooth radio band at transmission time. Surprising because Bluetooth is somewhat intentionally in one of the noisiest radio bands we've allowed to be extremely noisy.)
And even then you'll quickly run into problems when the attacker's receiver has better antennas in better locations than e.g. the user's laptop.
The problem here seems to be that implementations don't check whether a QR code has, in fact, been legitimately scanned at all.
Basically, there would need to be some device-specific private key included in the QR code which the authenticator could check somehow, but that trust needs to be established first somehow
One potential mitigation I could imagine is browsers actively trying to prevent FIDO QR codes from being rendered in web pages, but that's pretty difficult to stop
This is, of course, something that an attentive user can likely detect, as the browser can prevent web pages from mimicking the QR code workflow exactly, but a) webauthn is supposed to prevent this from happening, as the 'line of death' has proven to be a poor barrier, and b) there's no good way for the authenticator scanning the QR code to identify this line of death reliably.
https://textslashplain.com/2017/01/14/the-line-of-death/
(And, of course, the designers of this interface knew this could be an issue, which is why BLE is involved at all: so that this kind of attack can't just be done entirely remotely. But BLE is a bad way of identifying a particular device compared to, say, plugging in a USB port. Especially also imagine compromised IoT devices...)
At least that much seems reasonable to detect (e.g. by blocking FIDO URLs from being opened in browser, but also by the FIDO URL handler verifying whether the caller is a camera application or a browser).
One of the tricks is going to be avoiding Bluetooth logins in the long run. Microsoft has mentioned interest in finding better ways to better flow keys cross-platform. Also, BLE logins should be rare in general if handled well (BLE login once and only once on a different platform to add a key for that platform directly to the site) and we shouldn't be training users to expect "login via QR code" as the "norm". (Of course, yes, that's also a training situation with a lot of human failure modes.)
How much was this bounty if there was any? Looks like a 7.8 severity CVE [0].
[0] https://nvd.nist.gov/vuln/detail/CVE-2024-9956
This is similar to how you can't access HID (and by extension CTAP2 or U2F) or CCID (and by extension smart cards such as OpenPGP cards) over Web USB.
The problem here is that browsers allow redirecting users to the installed passkey implementation/"backend" in the same way that camera and dedicated QR scanner apps legitimately use to initiate cross-device authentication via (what used to be called) caBLE, right?
In other words, the attacker primes the user for an upcoming authentication on-device authentication, but in reality initiates an off-device authentication to their own device.
And the fix is presumably to not accept off-device authentication intents over anything that's not a QR scan, or at least filter them out in the browser?
Also, this vulnerability is very patchable; password phishing is incredibly hard to prevent.
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.
It was a little rough at first, but support is pretty good now. The only real concern is I don't know how to export passkeys out of 1Password if that were needed.
That'd make it a non-starter for me.
Bluetooth was a mistake.
How so? Unless you grant Bluetooth permissions to apps (that then start broadcasting identifiers) or explicitly make your device discoverable, this shouldn't really be a thing.
> What's the point of leaving it on all the time when most of the time it's just going to drain your battery and open you up to being tracked or exploited.
Just people with a wearable have at least one Bluetooth device connected to their phone at all times. Bluetooth headphones are also very popular.
We need hardened and privacy-protecting Bluetooth stacks, not blaming people for using their phones as designed and advertised.
https://www.nytimes.com/2013/07/15/business/attention-shoppe...
In what way is a modern Bluetooth device (let's assume both classic and LE) uniquely identifiable, other than for the caveats mentioned above? 2013 was indeed over a decade ago.
https://www.geoplugin.com/resources/geofencing-beacons-advan...
https://www.rfidjournal.com/news/long-range-ble-transmits-at...
https://easytechsolver.com/what-stores-use-bluetooth-beacons...
https://www.nytimes.com/interactive/2019/06/14/opinion/bluet...
> We need hardened and privacy-protecting Bluetooth stacks, not blaming people for using their phones as designed
Phones are explicitly designed to collect and leak as much of your personal data as possible. Nobody us going to implement hardened bluetooth stacks that protect you because that defeats the whole purpose. We're lucky they allow us to disable bluetooth at all. They've already changed airplane mode to continue using wireless and bluetooth even when enabled. Any useful features of bluetooth you might use with your phone is probably just bait to get to leak more of your data. They've removed headphone jacks to force your hand, but most people could at least make sure that bluetooth isn't enabled while it isn't in active use.
What benefit would phone manufacturers have from their devices being trackable via Bluetooth, or if it's not themselves, who is paying them for it?
Also, I'd love to see an answer to my original question: How exactly do you track a stock iPhone or Pixel with Bluetooth enabled? Neither transmit a persistent identifier, and none of the technologies linked change anything about that. They require explicit cooperation of an app on the device side, which is gated behind a prompt on both iOS and Android.
Your last link actually suggests the opposite: Bluetooth beacons allow apps to position themselves more accurately indoors and then do with that information whatever they want – if you grant that permission in the first place.
In Google's case, they use bluetooth to track the location of android users and the bluetooth devices near them. In addition to data collection, it helps their "Find my Device" network. I suspect Apple's system also uses bluetooth to identify nearby apple devices and beacons.
Obviously phone manufactures are primarily self-interested, but part of that also means offering extensive data collection opportunities to third parties such as app and accessory developers to attract people to their platform.
> Also, I'd love to see an answer to my original question: How exactly do you track a stock iPhone or Pixel with Bluetooth enabled?
While I don't have a pixel or an iphone, it does appear that there are ways to passively track these devices via bluetooth:
https://www.theregister.com/2021/10/22/bluetooth_tracking_de...
https://cec.gmu.edu/news/2025-02/find-my-hacker-how-apples-n...
Yes, these services being enabled by default isn't great, but if you're claiming that there's any data collection or intentional device broadcasting happening beyond that, i.e. at the base OS level, I'd be happy to see evidence of that (as I would also find that very concerning).
Regarding antenna/transmission chain/baseband fingerprinting: These are indeed concerning, and I hope there will be countermeasures available at some point. But these should theoretically affect all radio technologies, right? In that case, turning off (just) Bluetooth would not help much, given that phones have at least one other permanently enabled radio. It's a different story for devices that have only Bluetooth, of course.
Also according to my experience there is no "permission for bluetooth", it all falls under "Phone" or whatever other permission on Android.
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.
Applies to cryptography, authentication and so many things.