Hacker News Reader

Comment by jon-wood | Hacker News Reader

There's a whole set of fallbacks built in to the standard, including Bluetooth, local network connections, and going via a relay server. All of them eventually end up with your device signing something and handing that back to the browser on the other device to complete the authentication flow.

View on HN

Is this why I keep getting notifications that such-and-such a website wants access to devices on my local network? I've been denying those left and right lately and didn't understand what on earth they needed access to that for.

Android 17? If yes, then that's because they added a new permission specifically to block apps from LAN access, then bundled it together with "nearby devices" (one introduced earlier specifically to block Bluetooth and WiFi scanning and point-to-point connections) because apparently they believe the concept of "local network" is too difficult for normies to understand or something - and due to how it's implemented, even apps trying to talk via loopback with themselves get captured in scope, too. The UI won't tell you which is which, though.

That's likely Google's implementation of Local Network Access (https://wicg.github.io/local-network-access/).

The browser delegates passkey plumbing up to the core platform typically, so it already should have the appropriate permissions.

I cannot speak to how accurate your description is, but this description sounds like there are multiple weak points and multiple attack vectors that open this up to increased risk of compromise, undermining the very security stance it's supposed to provide.

See my response above... I believe the description is incorrect, and bluetooth is required to prove physical proximity.

The spec is quite thorough and well thought out in this regard. Despite what it "sounds like" when described, it is very secure, even with a variety of implementations. What is far weaker is that most sites that offer passkeys also offer a multitude of fallback recovery options.

AFAIK, the "scan this QR code" method of signing in with a passkey on a phone on a device w/o the passkey requires Bluetooth. There's some type of handshaking that goes on in order for you to prove you're in physical proximity of the device you are logging in on, to prevent phishing attacks.

Since I might have made someone mad... to clarify, as I understand it, Bluetooth is absolutely required for this "Scan the QR code" flow to work. However, it's also possible the actual authentication traffic to travel over a different pathway (wifi, cellular), but the bluetooth part is always required though to prove proximity. So on e.g. a library computer without Bluetooth enabled, you would not be able to log in with a passkey on your phone.

Right - you can treat the protocol as having:

1. Initiation (QR code, NFC in draft)

2. (Proximal) negotiation (BLE key exchange)

3. Communication (over websockets or a direct L2CAP channel)

The challenge is that a devices without bluetooth (at least today) don't have another common way to wirelessly judge proximity. A desktop/laptop without bluetooth likely either doesn't have NFC, or has bluetooth disabled by policy and would likely have cross-device passkeys disabled by policy as well.

Reply on news.ycombinator.com