Is the BLE advertisement message really necessary?

[Joshua Zhao]

When using a smartphone as a roaming authenticator, the phone needs to send out a BLE broadcast advertisement message after scanning the QR code. The reason for such a step is cited as a proximity check when using caBLE. I am having a hard time understanding why this is necessary.

By scanning the QR code, isn't it proven that the devices should be right next to each other if the authenticator can read the code embedded in the QR code? What specific threat we are guarding against with the extra broadcast BLE advertisement? If we are worried about a compromised browser, wouldn't the malicious code running on it have access to the broadcast message too? Am I missing something? The documents I can find didn't elaborate on the specifics.

The implementation would be simplified quite a bit without the need for the above step when using caBLE. Hence my question.

Any insights on this issue would be appreciated greatly.

Thanks,

Joshua

[Tim Cappalli]

The implementation would be simplified quite a bit without the need for the above step when using caBLE. Hence my question.

What are you trying to implement? CDA (hybrid) is implemented by platforms/clients. There is nothing that an RP or even passkey provider needs to implement.

 If we are worried about a compromised browser, wouldn't the malicious code running on it have access to the broadcast message too?

If your browser is compromised, all bets are off as TLS is likely also compromised.

The reason for such a step is cited as a proximity check when using caBLE. I am having a hard time understanding why this is necessary.

The BLE advertisement provides proof of proximity. QR codes offer no proof of proximity. They can be scanned from afar, rendered in a remote session, etc. Realistically nothing that is rendered on a screen, unless the device has no network access, offers any proof proximity.

---

From: fido...@fidoalliance.org <fido...@fidoalliance.org> on behalf of Joshua Zhao <zhao....@gmail.com>
Sent: Tuesday, October 24, 2023 10:39
To: FIDO Dev (fido-dev) <fido...@fidoalliance.org>
Subject: [FIDO-DEV] Is the BLE advertisement message really necessary?

 

--
You received this message because you are subscribed to the Google Groups "FIDO Dev (fido-dev)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fido-dev+u...@fidoalliance.org.
To view this discussion on the web visit https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/1341a16f-a250-4e29-8ee6-fe1c12fe4410n%40fidoalliance.org.

[Emil Lundberg]

Consider this attack:

1. Attacker sends you a phishing email. You click the link and end up on a fake login page.

2. The fake site intercepts your login attempt. The attacker launches Chrome on their own machine and opens the real website you think you're logging in to.

3. The attacker relays your login attempt to the real site.

4. The real site responds with a WebAuthn challenge, which triggers the Chrome authenticator selection popup. The attacker chooses the CaBLE option (manually or through input automation).

5. Chrome displays the pairing QR code.

6. The attacker extracts the pairing QR code and relays it to the fake site's server.

7. The fake site displays the QR code in a way that mimics what your browser's real pairing popup would look like.

8. You scan the QR code and your phone establishes a network link with the attacker's Chrome process (if we assume there was no Bluetooth advertisement).

9. Your phone signs the assertion, which gets returned to the attacker's Chrome process.

10. The attacker sends your assertion signature to the real website and hijacks your session.

This attack is made far less feasible by the Bluetooth advertisement. Without it the attacker could be around the globe, as described above. With it, the attacker must be within Bluetooth range in order for your phone to successfully establish the link with the attacker's Chrome process.

Emil Lundberg

Senior Software Engineer | Yubico

To view this discussion on the web visit https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/CH0PR00MB14159F512D7F69EE6DA00A1695DFA%40CH0PR00MB1415.namprd00.prod.outlook.com.

[Joshua Zhao]

Hi Emil,

Thank you so much for a detailed explanation! That's exactly what I was looking for to serve as a basis for debate.

I still don't understand why adding the BLE advertisement would change the equation here, specifically the following statement:

> With it, the attacker must be within Bluetooth range in order for your phone to successfully establish the link with the attacker's Chrome process.

If the fake site can display the chosen QR code to the user, its Chrome process can also relay the connection established with the user's phone to the attacker's Chrome process and it goes on from there. We didn't prevent anything with the addition of the BLE advertisement in the end. Did I miss anything here?

Additionally, the fake site would be under the wrong domain. Shouldn't the phishing attack be prevented by the domain name check? We shouldn't be using the passkey intended for the right domain in the session with the QR code displayed by the fake site anyways. 

I really want to understand the purpose for this mechanism, as I just don't want unnecessary dependencies. Are such BLE advertisements pretty reliable? 

Thanks again,

Joshua

[Joshua Zhao]

Hi Tim,

You are right that caBLE is implemented by platforms. It's just that sometimes the BLE advertisements are not received, so I wish to avoid unnecessary dependencies if possible.

If BLE could work reliably, there would be so much more we can do in utilizing such a communication channel.

Thanks,

Joshua

[My1]

well the fun part is that just with qr you dont need a compromised browser, an evil qr code could be shown by just a phishing website well enough to trick most people, in fact if I was fast I could send you a fido qr over chat and you could try scanning it but the lack of BT makes it not actually work.

and if it's just a phishing site, it cant relay the messages needed easily as you'd need to enable WebBT, and frankly I wouldnt be surprised if webBT has protections against this idea.

Regarding domain-based security, this is only in regards to the devices actually involved in the authentication process, aka the attacker's browser (which can do what the attacker wants anyway) and the victim's phone (where it looks legit as you wanna sign to e.g. the Google account anyway). The victim's browser wouldnt even be part of the equation.

I personally have my own gripes with the BT too since it feels it doesnt work most of the time, but Linux and Wireless drivers are always a fun thing, but I learned that in the process where it searches, you might be able to plug in your phone via USB and let it do its stuff that way. (kinda sad cross device FIDO isnt offered when the client device doesnt have a BT capability even if the capability of USB exists)

A compromised browser is the least of our worries because if the browser is compromised, all bets are off, even if you were to use an actual FIDO-USB Device like a Yubikey or whatever. the only security you could have would be a FIDO-Device with Display such as the Mooltipass or the FIDO-enabled Cryptocoin wallets from several makers who can show you either the rpID itself or, if operating on CTAP1, a prepresentation of the appid hash), but even then a malicious browser could just wait for a moment or make you believe you are actually signing into that specific service instead of just spoofing left right and center.

To view this discussion on the web visit https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/d1b5c7be-708c-4b32-89ae-d559f6698433n%40fidoalliance.org.

[Joshua Zhao]

OK. We are not worrying about a compromised browser. I agree that all bets are off in this case. That's why I am having trouble picturing an attack scenario where the extra BLE advertisement will make a difference.

If a victim is scanning a QR code rendered by a fake site, the browser would enforce that the domain included in the authentication request should match that of the fake site, no? That's why I don't expect that the phone would use the passkey for the real site. I still don't have a scenario for a potential attack that can only be prevented by the BLE message.

Thanks,

Joshua

[My1]

I think  you are misunderstanding,

you are not having a browser on a wrong site start an actual FIDO transaction (where the protections would actually work), but just displayed on a website, hell the FIDO qr code if presented at the right time could be on anything, it could literally be on e.g. a digital billboard, or heck even a piece of paper for example, tho obviously an attack using that would be much harder to get someone to actually go and transmit a login that way.

in a qr phishing scenario the victim's browser is completely taken out of the equation, it just shows a qr code from a website its told to display, it neither knows that the qr code is a FIDO qr code, nor is it currently part of any FIDO interactions it could protect.

and on the phone it would just ask whether to login to e.g. google, but at that point you are logging in the attacker since THEIR browser initiated the FIDO transaction.

I mean I could literally send you a FIDO qr code as an attachment to this email and the only thing blocking you from accidentially doing something dumb is the proximity check.

Regards

My1

[Joshua Zhao]

Thank you for elaborating! But I am really confused now. Are we still talking about the login with roaming authenticator FIDO flow? I was not expecting a random QR code which a victim scans and then blindly authorize the use of the passkey. I don't even know that the above scenario is covered in FIDO. This looks an utterly dumb thing for a user to do. I thought that a user was to pick a way to authenticate and a QR code was triggered as a result. Do you mean that a malicious site somehow pops up a QR code in its place? But how? If the malicious site could do the above, how do we know that it would not be able to receive the BLE broadcast? In this case, what prevents it from invoking the browser API to trigger the CTAP2 process and listen for such broadcast messages? The question is again: with the given attack, does the BLE broadcast make any difference?

Best regards,

Joshua

[My1]

I was using that as an example, we obviously dont expect people scanning printed or billboard qrs, but the fun part is that a site could claim to be google or whatever (on a different domain obviously) and just NOT start an ACTUAL FIDO transaction, but just make it look like one, especially as most people likely are not trained to know how to distinguish whether a "pop up" is real or just part of the website.

while the real popup does ever so slightly peek outside the website into the space below the address bar, it is so miniscule people wouldnt know.

and if a website went convincingly enough "please scan this qr to verify your connection to google" and the smartphone pops up that google wants to authenticate that, this gets very fun very fast.

[Joost van Dijk]

Maybe it helps to realize that the QR code doesn’t contain anything related to the WebAuthn API call itself (let’s say a navigator.credentials.get), but only the transport.

That means the phishing protection inherent to FIDO does not apply here.

The QR code is used to establish a secure channel over the Internet between the authenticator (a mobile device) and the browser, over which CTAP messages are exchanged, just like they are normally exchanged over USB when using a USB security key.

Without a proximity check, that would enable Mallory (the attacker) to initiate a transaction with an RP, and trick you into establishing the CTAP tunnel between your mobile device and Mallory’s browser. If you would fall for that, Mallory would be signed in with your account.

The BLE proximity check prevents this attack unless Mallory is in proximity to your phone. Also, the BLE advertisement helps in securing the tunnel by providing part of the key material.

Does this help?

Joost van Dijk

On 25 Oct 2023, at 08:14, Joshua Zhao <zhao....@gmail.com> wrote:

Thank you for elaborating! But I am really confused now. Are we still talking about the login with roaming authenticator FIDO flow? I was not expecting a random QR code which a victim scans and then blindly authorize the use of the passkey. I don't even know that the above scenario is covered in FIDO. This looks an utterly dumb thing for a user to do. I thought that a user was to pick a way to authenticate and a QR code was triggered as a result. Do you mean that a malicious site somehow pops up a QR code in its place? But how? If the malicious site could do the above, how do we know that it would not be able to receive the BLE broadcast? In this case, what prevents it from invoking the browser API to trigger the CTAP2 process and listen for such broadcast messages? The question is again: with the given attack, does the BLE broadcast make any difference?

To view this discussion on the web visit https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/9336b511-5794-49a6-aeff-7e0b90c56bban%40fidoalliance.org.

[Emil Lundberg]

Additionally, the fake site would be under the wrong domain. Shouldn't the phishing attack be prevented by the domain name check?

If a victim is scanning a QR code rendered by a fake site, the browser would enforce that the domain included in the authentication request should match that of the fake site, no?

 

I'll try to add to My1's explanation: yes, the attack would be prevented by the domain check if the WebAuthn API had been invoked on the fake site, on the victim's machine. But in this attack scenario, the WebAuthn API is instead invoked only on the real site, on the attacker's machine. The attacker just relays the QR code to be displayed as an ordinary image on the fake site. So no, there would be no domain check on the fake site, because the WebAuthn API is never invoked on the fake site.

I'll restate the sequence from earlier, with some additional annotations in italic font:

1. Attacker sends you a phishing email. On your machine: You click the link and end up on a fake login page: evil.org.

2. The fake site intercepts your login attempt. On the attacker's machine: The attacker launches Chrome and opens the website you think you're logging in to: real.com.

3. On the attacker's machine, on real.com: The attacker relays your login attempt to the real.com backend.

4. The real.com backend responds with a WebAuthn challenge, which (on the attacker's machine, on real.com) triggers the Chrome authenticator selection popup. The attacker chooses the CaBLE option (manually or through input automation).

5. On the attacker's machine, on real.com: Chrome displays the pairing QR code.

6. On the attacker's machine, on real.com: The attacker extracts the pairing QR code and relays it to the fake site's server.

7. On your machine, on evil.org: The fake site displays the QR code (as an ordinary <img> in the webpage DOM) in a way that mimics what your browser's real pairing popup would look like. The fake site DOES NOT invoke the WebAuthn API, so no domain check is done.

8. On your machine, on evil.org: You scan the QR code and your phone establishes a network link with the attacker's Chrome process (running on the attacker's machine, on the real.org webpage) (if we assume there was no Bluetooth advertisement).

8.1: The attacker's Chrome process sends an assertion request for real.com over the network link.

9. On your phone, with RP ID "real.com": Your phone signs the assertion, which gets returned to the attacker's Chrome process.

10. On the attacker's machine, on real.com: The attacker sends your assertion signature to the real website and hijacks your session.

Perhaps this makes things clearer?

If the fake site can display the chosen QR code to the user, its Chrome process can also relay the connection established with the user's phone to the attacker's Chrome process and it goes on from there. We didn't prevent anything with the addition of the BLE advertisement in the end. Did I miss anything here?

In the real protocol, the BLE advertisement carries a nonce which the client is required to prove possession of. So in step (8), your phone would send a BLE advertisement containing this nonce and then refuse to establish the network link unless the client (Chrome on the attacker's machine) can prove possession of the nonce. Of course the attacker cannot present such a proof, unless they have a Bluetooth radio in range of the phone's BLE advertisement. Otherwise the attacker's only presence within BLE range is on the fake site in your browser. Presumably the fake site's JavaScript does not have access to BLE, so the fake site cannot capture the BLE advertisement to relay it to the attacker's Chrome process. And of course, an attempt to invoke the WebAuthn API on the fake site would indeed fail the domain check - either your browser blocks the assertion request with RP ID "real.com", or your browser and phone do successfully establish a network link but generate an assertion signature for fake.org instead of real.com, which would be rejected by the real.com backend.

Does that help?

Emil Lundberg

Senior Software Engineer | Yubico

To view this discussion on the web visit https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/AF04831A-CF2A-4E3D-ABA8-26650A288EE9%40gmail.com.

[Anders Rundgren]

FWIW. Years ago I proposed an alternative to QR based on NFC:
https://github.com/w3c/web-nfc/issues/128

Since then NFC fell of the chart for PCs.

I believe lots of existing authentication solutions are vulnerable to the phishing attack described below.

Thanx,
Anders

>> A compromised browser is the least of our worries because if the browser is compromised, *all bets are off*, even if you were to use an actual FIDO-USB Device like a Yubikey or whatever. the only security you could have would be a FIDO-Device with Display such as the Mooltipass or the FIDO-enabled Cryptocoin wallets from several makers who can show you either the rpID itself or, if operating on CTAP1, a prepresentation of the appid hash), but even then a malicious browser could just wait for a moment or make you believe you are actually signing into that specific service instead of just spoofing left right and center.

>>
>> Am Di., 24. Okt. 2023 um 22:11 Uhr schrieb Joshua Zhao <zhao....@gmail.com>:
>>
>> Hi Tim,
>>
>> You are right that caBLE is implemented by platforms. It's just that sometimes the BLE advertisements are not received, so I wish to avoid unnecessary dependencies if possible.
>>
>> If BLE could work reliably, there would be so much more we can do in utilizing such a communication channel.
>>
>> Thanks,
>> Joshua
>>
>> On Tuesday, October 24, 2023 at 10:48:16 AM UTC-7 Tim Cappalli wrote:
>>
>> The implementation would be simplified quite a bit without the need for the above step when using caBLE. Hence my question.
>>
>>
>> What are you trying to implement? CDA (hybrid) is implemented by platforms/clients. There is nothing that an RP or even passkey provider needs to implement.
>>
>>
>>  If we are worried about a compromised browser, wouldn't the malicious code running on it have access to the broadcast message too?
>>
>>
>> If your browser is compromised, all bets are off as TLS is likely also compromised.
>>
>>
>> The reason for such a step is cited as a proximity check when using caBLE. I am having a hard time understanding why this is necessary.
>>
>>
>> The BLE advertisement provides proof of proximity. QR codes offer no proof of proximity. They can be scanned from afar, rendered in a remote session, etc. Realistically nothing that is rendered on a screen, unless the device has no network access, offers any proof proximity.
>>

>> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>> *From:* fido...@fidoalliance.org <fido...@fidoalliance.org> on behalf of Joshua Zhao <zhao....@gmail.com>
>> *Sent:* Tuesday, October 24, 2023 10:39
>> *To:* FIDO Dev (fido-dev) <fido...@fidoalliance.org>
>> *Subject:* [FIDO-DEV] Is the BLE advertisement message really necessary?

>> When using a smartphone as a roaming authenticator, the phone needs to send out a BLE broadcast advertisement message after scanning the QR code. The reason for such a step is cited as a proximity check when using caBLE. I am having a hard time understanding why this is necessary.
>>
>> By scanning the QR code, isn't it proven that the devices should be right next to each other if the authenticator can read the code embedded in the QR code? What specific threat we are guarding against with the extra broadcast BLE advertisement? If we are worried about a compromised browser, wouldn't the malicious code running on it have access to the broadcast message too? Am I missing something? The documents I can find didn't elaborate on the specifics.
>>
>> The implementation would be simplified quite a bit without the need for the above step when using caBLE. Hence my question.
>>
>> Any insights on this issue would be appreciated greatly.
>>
>> Thanks,
>> Joshua
>> --
>> You received this message because you are subscribed to the Google Groups "FIDO Dev (fido-dev)" group.
>> To unsubscribe from this group and stop receiving emails from it, send an email to fido-dev+u...@fidoalliance.org.

>> To view this discussion on the web visit https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/1341a16f-a250-4e29-8ee6-fe1c12fe4410n%40fidoalliance.org <https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/1341a16f-a250-4e29-8ee6-fe1c12fe4410n%40fidoalliance.org?utm_medium=email&utm_source=footer>.

>>
>> --
>> You received this message because you are subscribed to the Google Groups "FIDO Dev (fido-dev)" group.
>> To unsubscribe from this group and stop receiving emails from it, send an email to fido-dev+u...@fidoalliance.org.
>>

>> To view this discussion on the web visit https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/d1b5c7be-708c-4b32-89ae-d559f6698433n%40fidoalliance.org <https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/d1b5c7be-708c-4b32-89ae-d559f6698433n%40fidoalliance.org?utm_medium=email&utm_source=footer>.

>>
>> --
>> You received this message because you are subscribed to the Google Groups "FIDO Dev (fido-dev)" group.

>> To unsubscribe from this group and stop receiving emails from it, send an email to fido-dev+u...@fidoalliance.org <mailto:fido-dev+u...@fidoalliance.org>.
>> To view this discussion on the web visit https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/9336b511-5794-49a6-aeff-7e0b90c56bban%40fidoalliance.org <https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/9336b511-5794-49a6-aeff-7e0b90c56bban%40fidoalliance.org?utm_medium=email&utm_source=footer>.

>
> --
> You received this message because you are subscribed to the Google Groups "FIDO Dev (fido-dev)" group.

> To unsubscribe from this group and stop receiving emails from it, send an email to fido-dev+u...@fidoalliance.org <mailto:fido-dev+u...@fidoalliance.org>.
> To view this discussion on the web visit https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/AF04831A-CF2A-4E3D-ABA8-26650A288EE9%40gmail.com <https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/AF04831A-CF2A-4E3D-ABA8-26650A288EE9%40gmail.com?utm_medium=email&utm_source=footer>.

[My1]

I would guess NFC is fairly rare for PCs to have while Bluetooth is pretty much everywhere on Laptops and even on Tower PCs (which iirc are going down anyway) BT is gaining traction.

[Anders Rundgren]

On 2023-10-25 13:37, My1 wrote:
> I would guess NFC is fairly rare for PCs to have while Bluetooth is pretty much everywhere on Laptops and even on Tower PCs (which iirc are going down anyway) BT is gaining traction.

Of course. The Web NFC folks did not see Web payments or Web authentication as important use cases.

I'm thinking about doing a PoC with Chrome and an external reader just to verify the concept.

Anders

>
> Am Mi., 25. Okt. 2023 um 10:23 Uhr schrieb Anders Rundgren <anders.ru...@gmail.com <mailto:anders.ru...@gmail.com>>:
>
> FWIW. Years ago I proposed an alternative to QR based on NFC:

> https://github.com/w3c/web-nfc/issues/128 <https://github.com/w3c/web-nfc/issues/128>

> >>                     *From:* fido...@fidoalliance.org <mailto:fido...@fidoalliance.org> <fido...@fidoalliance.org <mailto:fido...@fidoalliance.org>> on behalf of Joshua Zhao <zhao....@gmail.com <mailto:zhao....@gmail.com>>

> >>                     *Sent:* Tuesday, October 24, 2023 10:39

> >>                     *To:* FIDO Dev (fido-dev) <fido...@fidoalliance.org <mailto:fido...@fidoalliance.org>>

> >>                     *Subject:* [FIDO-DEV] Is the BLE advertisement message really necessary?
> >>                     When using a smartphone as a roaming authenticator, the phone needs to send out a BLE broadcast advertisement message after scanning the QR code. The reason for such a step is cited as a proximity check when using caBLE. I am having a hard time understanding why this is necessary.
> >>
> >>                     By scanning the QR code, isn't it proven that the devices should be right next to each other if the authenticator can read the code embedded in the QR code? What specific threat we are guarding against with the extra broadcast BLE advertisement? If we are worried about a compromised browser, wouldn't the malicious code running on it have access to the broadcast message too? Am I missing something? The documents I can find didn't elaborate on the specifics.
> >>
> >>                     The implementation would be simplified quite a bit without the need for the above step when using caBLE. Hence my question.
> >>
> >>                     Any insights on this issue would be appreciated greatly.
> >>
> >>                     Thanks,
> >>                     Joshua
> >>                     --
> >>                     You received this message because you are subscribed to the Google Groups "FIDO Dev (fido-dev)" group.

> >>                     To unsubscribe from this group and stop receiving emails from it, send an email to fido-dev+u...@fidoalliance.org <mailto:fido-dev%2Bu...@fidoalliance.org>.
> >>                     To view this discussion on the web visit https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/1341a16f-a250-4e29-8ee6-fe1c12fe4410n%40fidoalliance.org <https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/1341a16f-a250-4e29-8ee6-fe1c12fe4410n%40fidoalliance.org> <https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/1341a16f-a250-4e29-8ee6-fe1c12fe4410n%40fidoalliance.org?utm_medium=email&utm_source=footer <https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/1341a16f-a250-4e29-8ee6-fe1c12fe4410n%40fidoalliance.org?utm_medium=email&utm_source=footer>>.

> >>
> >>                 --
> >>                 You received this message because you are subscribed to the Google Groups "FIDO Dev (fido-dev)" group.

> >>                 To unsubscribe from this group and stop receiving emails from it, send an email to fido-dev+u...@fidoalliance.org <mailto:fido-dev%2Bu...@fidoalliance.org>.
> >>
> >>                 To view this discussion on the web visit https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/d1b5c7be-708c-4b32-89ae-d559f6698433n%40fidoalliance.org <https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/d1b5c7be-708c-4b32-89ae-d559f6698433n%40fidoalliance.org> <https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/d1b5c7be-708c-4b32-89ae-d559f6698433n%40fidoalliance.org?utm_medium=email&utm_source=footer <https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/d1b5c7be-708c-4b32-89ae-d559f6698433n%40fidoalliance.org?utm_medium=email&utm_source=footer>>.

> >>
> >> --
> >> You received this message because you are subscribed to the Google Groups "FIDO Dev (fido-dev)" group.

> >> To unsubscribe from this group and stop receiving emails from it, send an email to fido-dev+u...@fidoalliance.org <mailto:fido-dev%2Bunsu...@fidoalliance.org> <mailto:fido-dev+u...@fidoalliance.org <mailto:fido-dev%2Bunsu...@fidoalliance.org>>.
> >> To view this discussion on the web visit https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/9336b511-5794-49a6-aeff-7e0b90c56bban%40fidoalliance.org <https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/9336b511-5794-49a6-aeff-7e0b90c56bban%40fidoalliance.org> <https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/9336b511-5794-49a6-aeff-7e0b90c56bban%40fidoalliance.org?utm_medium=email&utm_source=footer <https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/9336b511-5794-49a6-aeff-7e0b90c56bban%40fidoalliance.org?utm_medium=email&utm_source=footer>>.

> >
> > --
> > You received this message because you are subscribed to the Google Groups "FIDO Dev (fido-dev)" group.

> > To unsubscribe from this group and stop receiving emails from it, send an email to fido-dev+u...@fidoalliance.org <mailto:fido-dev%2Bunsu...@fidoalliance.org> <mailto:fido-dev+u...@fidoalliance.org <mailto:fido-dev%2Bunsu...@fidoalliance.org>>.
> > To view this discussion on the web visit https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/AF04831A-CF2A-4E3D-ABA8-26650A288EE9%40gmail.com <https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/AF04831A-CF2A-4E3D-ABA8-26650A288EE9%40gmail.com> <https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/AF04831A-CF2A-4E3D-ABA8-26650A288EE9%40gmail.com?utm_medium=email&utm_source=footer <https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/AF04831A-CF2A-4E3D-ABA8-26650A288EE9%40gmail.com?utm_medium=email&utm_source=footer>>.
>

[Joshua Zhao]

Thank you all for helping me understand the attack scenario that motivated the proximity check! Emil's descriptions left no ambiguity, which are extremely helpful.

In this particular case, the victim authorizes the use of a passkey for the real site after scanning a QR code displayed by a fake site. The proximity check does help to guard against such phishing attacks. However, wouldn't it be better to enlist help from browsers to enforce the following behavior: only the browser can pop up a special credential selection window distinctively recognizable to users (like Windows Hello) and we can only trigger the popup through system APIs?

The proximity-checking method will be problematic when access to bluetooth is enabled for websites down the road. It doesn't seem to be a long-term solution if we are concerned about the above-mentioned somewhat weird phishing case.

Thanks again,

Joshua

[My1]

I'd say even the win hello Window isn't overly distinct if you don't try to confirm its "window" status by alt tabbing around or dragging itnout of the browser viewport.

The only thing that'd be real distinct is the secure desktop like on a UAC request

[Uwe]

I want to add my 2 cents. It may be possible to do this without Bluetooth at all. The trick is to leverage the https connection, that is the certificate of it. If you click into the address bar all elements in the DOM get the blur event. Then they won't get any event when you click on the lock icon. But you will observe that the content will darken at exactly that moment. If it goes dark at any other moment, the site is fake. Moreover you can get information about the certificate, especially the fingerprint. Together the fingerprint of the certificate and the QR code, which hasn't gone darker, hopefully, together with the content (another sign for a fake), should contain enough information to verify that you have an authentic connection with the server you want to connect to. And all packed up in one convincing image. The only work to do yet is to write the software, that evaluates the image into a yes! (Or no)answer to the question of authentication. 

[My1]

You are aware that FIDO is supposed to work for the masses aren't you? 

It is not just a security toy for us nerds to play around with, it's supposed to get widespread adoption and if you need to check the specific timing ofnsome darkening event, otherwise it could be easy to scam you out of your login that's not gonna be something that adopts easily. 

[Uwe]

Yes, I am aware. The thing in this case is that the timing gives the fake away before (!) Anybody does the login. But the resulting picture, independent of any timing (!), contains any information the verifying software (!) needs to check for a fake. So you can't login at a fake site! But you will have, at that time, gotten your smartphone out of your pocket, entered your PIN and snapped that picture. All for nothing. To spare you that time, I volunteered some information, that would make an early abort possible. 

[Joshua Zhao]

Sorry to revive an old thread. I'm still having some lingering doubt on this topic.

Does anyone know the status on web Bluetooth? Will there likely be a day when a browser session might be able to listen on BLE broadcast advertisements? If so, does this mean we will have to devise another mechanism to defend against this specific phishing attack?

Protecting a user who bluntly ignores the fake site's URL on the address bar seems like a tall order. I also truly believe that allowing the display of QR code prompt indistinguishable from ones rendered by the client browser is not acceptable and is too difficult to defend against. The client should not be easily bypassed, which may well be the key to solve this problem. Does this make sense? I would like to see a way to put the display of passkey login prompt under browser control only.

Thanks,

Joshua

[Tim Cappalli]

Cross-Device Authentication (e.g. hybrid transport) is not a web-exposed layer, so there is no need for a web platform API like Web Bluetooth.

To view this discussion on the web visit https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/72325664-d017-46d2-8459-7b2eb7a4467cn%40fidoalliance.org.

[Xinhua (Joshua) Zhao]

On Tue, Dec 19, 2023 at 5:54 AM Tim Cappalli <Tim.Ca...@microsoft.com> wrote:
>
> Cross-Device Authentication (e.g. hybrid transport) is not a web-exposed layer, so there is no need for a web platform API like Web Bluetooth.

I should have elaborated on this. My concern is that an unsuspecting
user may agree to enable Web Bluetooth when prompted by the fake site
in the attack scenario detailed by Emil. The Web Bluetooth feature is
still hidden behind an experimental flag, so it's not a problem today.
But sooner or later, this will become an issue. when the fake site can
intercept the BLE advertisement messages as well. As a result, the
hybrid flow can be hijacked to the attacker's browser with the
intercepted code contained in the BLE advertisement.

I find it problematic that the browser client is so easily bypassed in
the attack scenario in the first place, and would like to see the
chain from the RP to the authenticator solidified by some enforcement
mechanism built in the browsers. Has this been explored before? I'd
like to follow up on that thread if there were past discussions on
this issue.

Thanks,
Joshua

[rjhal...@gmail.com]

Windows 10 and 11 with Chrome and either Titan or Affirmed Auth in use every day and all is good. Indeed, very good.

 

As for phishing, absent a way to prevent humans from making honest mistakes, it will remain a concern indefinitely.

 

Season’s greetings to all,

Rick

To view this discussion on the web visit https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/72325664-d017-46d2-8459-7b2eb7a4467cn%40fidoalliance.org.