3 ms·
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 devic
by rcxdude 2y ago
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.
https://textslashplain.com/2017/01/14/the-line-of-death/ 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...)
- lxgr 2y agoBut here, no pixels have been scanned at all. 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).
- rcxdude 2y agoYeah, 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'
- WorldMaker 2y agoThough 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.)