For the desktop scenario, the reason that "trust gap" exists is that the chain of custody is too murky and if Keyri solves that I didn't see how. Of course maybe that's your secret sauce.
Specifically, how does the phone know which web page its owner is looking at on their laptop when they scanned the QR code ? You need to arrange that it's not possible to take the QR code generated for you and present it to a sucker for them to scan instead so that you're signed in as them and like I said, if Keyri does that then I don't see how.
Specifically, how does the phone know which web page its owner is looking at on their laptop when they scanned the QR code? You need to arrange that it's not possible to take the QR code generated for you and present it to a sucker for them to scan instead so that you're signed in as them...
Isn't this a problem then with WhatsApp Web login too which shows a QR code (presumably not tied to any one account as the web-client seemingly generates it without any user-input) that the app then scans to initiate auth?
I was also wondering if its a severe vulnerability, given that the phone (roaming authenticator) continues to be in the possession of the victim, and they retain the ability to revoke other keys / tokens (which could additionally be authz restricted) shared with untrusted devices (client/platform), much like how one would revoke leaked API keys?
Btw, am I correct in guessing that FIDO2 solves this "trust gap" problem with CTAP2 relying on BLE, USB, NFC to prove user-presence? Thx.
am I correct in guessing that FIDO2 solves this "trust gap" problem with CTAP2 relying on BLE, USB, NFC to prove user-presence?
FIDO2 isn't interested in this problem at all. From the point of view of FIDO2 the rpId ("Relying Party ID" the thing that distinguishes Apple from Facebook) is just arbitrary data selected by the application.
WebAuthn solves the problem by trusting the web browser to know which web site you're visiting. Specifically, the relying party (a web site you're trying to sign into) gets to pick a DNS name you'll authenticate against but the browser matches this DNS name against the HTTPS URL you're looking at, and rejects requests that don't match. The rpId is based on this DNS name, so a phishing site can't work.
e.g. You may think this page is from your bank, but your browser knows it's https://fake-bank.example/ and won't give it WebAuthn credentials for real-bank.example even though you firmly believe that's where you are.
Isn't this a problem then with WhatsApp Web login too
Yes, it's an issue with WhatsApp QR login and every other QR login implementation.
I was also wondering if its a severe vulnerability
It can be severe if the attacker only needs to be authenticated in the victim's account for a short while to do damage. For example, to withdraw cryptocurrency from an exchange account. Or, in the case of WhatsApp, to extract damaging personal info. Persistent access is not a prerequisite for the ability to do harm.
Am I correct in guessing that FIDO2 solves this "trust gap" problem with CTAP2 by relying on BLE, USB, NFC to prove user-presence
Partially correct - there's two-way communication in FIDO2/CTAP2 in which the roaming authenticator confirms the "identity" of the web session before sending an auth request. The user-presence aspect is incidental to these three protocols. We do the same thing, just with CV
Nail on the head. That's the problem that the secret sauce solves. Without going too much in to it (because I don't think it's a very defensible moat at the moment), the phone sees stuff on the screen other than the QR code, which bad actors cannot present to victims.
So are you saying that even if the bad actors found out how the secret sauce works, they would not be able to spoof a legit page? In other words, is the obscurity in the CV part purely for competitive reasons, or does it also serve a security purpose?
Yes, even if bad actors figured out the secret sauce, they couldn't defeat it easily. It's possible, but if they hack you the way they'd have to hack you in order to defeat our CV element, you'd have much bigger problems to worry about. So yes, the lack of disclosure is for competitive reasons, not for security purposes.
Comments
For the desktop scenario, the reason that "trust gap" exists is that the chain of custody is too murky and if Keyri solves that I didn't see how. Of course maybe that's your secret sauce.
Specifically, how does the phone know which web page its owner is looking at on their laptop when they scanned the QR code ? You need to arrange that it's not possible to take the QR code generated for you and present it to a sucker for them to scan instead so that you're signed in as them and like I said, if Keyri does that then I don't see how.
Isn't this a problem then with WhatsApp Web login too which shows a QR code (presumably not tied to any one account as the web-client seemingly generates it without any user-input) that the app then scans to initiate auth?
I was also wondering if its a severe vulnerability, given that the phone (roaming authenticator) continues to be in the possession of the victim, and they retain the ability to revoke other keys / tokens (which could additionally be authz restricted) shared with untrusted devices (client/platform), much like how one would revoke leaked API keys?
Btw, am I correct in guessing that FIDO2 solves this "trust gap" problem with CTAP2 relying on BLE, USB, NFC to prove user-presence? Thx.
FIDO2 isn't interested in this problem at all. From the point of view of FIDO2 the rpId ("Relying Party ID" the thing that distinguishes Apple from Facebook) is just arbitrary data selected by the application.
WebAuthn solves the problem by trusting the web browser to know which web site you're visiting. Specifically, the relying party (a web site you're trying to sign into) gets to pick a DNS name you'll authenticate against but the browser matches this DNS name against the HTTPS URL you're looking at, and rejects requests that don't match. The rpId is based on this DNS name, so a phishing site can't work.
e.g. You may think this page is from your bank, but your browser knows it's https://fake-bank.example/ and won't give it WebAuthn credentials for real-bank.example even though you firmly believe that's where you are.
Yes, it's an issue with WhatsApp QR login and every other QR login implementation.
It can be severe if the attacker only needs to be authenticated in the victim's account for a short while to do damage. For example, to withdraw cryptocurrency from an exchange account. Or, in the case of WhatsApp, to extract damaging personal info. Persistent access is not a prerequisite for the ability to do harm.
Partially correct - there's two-way communication in FIDO2/CTAP2 in which the roaming authenticator confirms the "identity" of the web session before sending an auth request. The user-presence aspect is incidental to these three protocols. We do the same thing, just with CV
Nail on the head. That's the problem that the secret sauce solves. Without going too much in to it (because I don't think it's a very defensible moat at the moment), the phone sees stuff on the screen other than the QR code, which bad actors cannot present to victims.
So are you saying that even if the bad actors found out how the secret sauce works, they would not be able to spoof a legit page? In other words, is the obscurity in the CV part purely for competitive reasons, or does it also serve a security purpose?
Yes, even if bad actors figured out the secret sauce, they couldn't defeat it easily. It's possible, but if they hack you the way they'd have to hack you in order to defeat our CV element, you'd have much bigger problems to worry about. So yes, the lack of disclosure is for competitive reasons, not for security purposes.