2 ms·

In SQRL the target domain is used as part of the per-domain key derivation from the master key. It’s basically stateless per-domain identity from a single maste

• dwaite 5y ago
  No. The user has to know they are interacting _directly_ with the authentic site, vs a malicious party intermediating the QR-based login. There is no way to solve this with mere QR codes; you want the communication channel itself to be authenticated, and that communication channel is abstracted completely away. So you can authenticate and create _a_ session, but you aren't sure it is actually going to be your session vs an attacker's. WebAuthn has the code managing that channel (e.g. native code within the browser or underlying OS) craft an authentication request specifically for the site being accessed. It does this over a separate communication channel to the authenticator device, or internally to the underlying platform. IMHO, the biggest risk to WebAuthn is arbitrary client software, as a 'fake' browser can misrepresent why you are tapping to create sessions into other websites. This is why several operating systems lock down the ability to talk to FIDO keys directly over USB/NFC/Bluetooth, and instead provide a native API requiring entitlements. Normal apps may get credentials only for their own sites, while a Browser may be vetted at a higher level of scrutiny to get credentials for any site. Actually, no, the biggest risk remains script injection - XSS and WebExtensions.