3 ms·

On a related note, hasn't this been solved by SQRL [0]? > SQRL (pronounced "squirrel") or Secure, Quick, Reliable Login (formerly Secure QR Login) is a draft o

On a related note, hasn't this been solved by SQRL [0]? > SQRL (pronounced "squirrel") or Secure, Quick, Reliable Login (formerly Secure QR Login) is a draft open standard for secure website login and authentication. The software typically uses a link of the scheme sqrl:// or optionally a QR code, where a user identifies via a pseudonymous zero-knowledge proof rather than providing a user ID and password. This method is thought to be impervious to a brute force password attack or data breach. It shifts the burden of security away from the party requesting the authentication and closer to the operating system implementation of what is possible on the hardware, as well as to the user. SQRL was proposed by Steve Gibson of Gibson Research Corporation in October 2013 as a way to simplify the process of authentication without the risk of revelation of information about the transaction to a third party. I think it's a shame that there has not been a more popular adoption of this authentication method. [0]: https://en.wikipedia.org/wiki/SQRL https://en.wikipedia.org/wiki/SQRL

tialaramex 5y ago
SQRL sorta-kinda solves most of the problems WebAuthn solves, but only if you chose to configure it that way and your users are holding it right. For a security feature that's not good enough. Phishing is the one that gets me, because we know it's a crucial threat and WebAuthn solves it. Done. Google just gave employees Security Keys and the problem went away. SQRL ends up in most cases with the "phishing prevention" relying on the user, the person phishing intentionally exploits, to determine they are being phished. That's not a strategy for success. If Grandma didn't realise this isn't the real web site when her email linked it, she's also not going to realise when there's a typo in the name her SQRL client displays. And then it's game over.
- tatersolid 5y ago
  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 master secret. This provides strong phishing protection.
  - 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.
dwaite 5y ago
SQRL has weak anti-phishing protections. Basically you can't tell if the QR code is being displayed by the legitimate site or another site which is proxying the legitimate site. WebAuthn integrates with the browser itself, and both does per-site keys and identifies the site in its cryptographic response. You would need to compromise the site or infrastructural pieces like DNS and TLS to break WebAuthn's phishing protections. FWIW, Mutual TLS and Kerberos are the other two widely known systems here, with slightly better phishing protections because they operate below the "XSS" layer of modern browsers. However, that also means they require infrastructure investment, and are generally impractical to deploy outside environments with device management. See also https://krebsonsecurity.com/2018/07/google-security-keys-neutralized-employee-phishing/ https://krebsonsecurity.com/2018/07/google-security-keys-neu...

tialaramex 5y ago

SQRL sorta-kinda solves most of the problems WebAuthn solves, but only if you chose to configure it that way and your users are holding it right. For a security feature that's not good enough. Phishing is the one that gets me, because we know it's a crucial threat and WebAuthn solves it. Done. Google just gave employees Security Keys and the problem went away. SQRL ends up in most cases with the "phishing prevention" relying on the user, the person phishing intentionally exploits, to determine they are being phished. That's not a strategy for success. If Grandma didn't realise this isn't the real web site when her email linked it, she's also not going to realise when there's a typo in the name her SQRL client displays. And then it's game over.

tatersolid 5y ago
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 master secret. This provides strong phishing protection.
- 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.

dwaite 5y ago

SQRL has weak anti-phishing protections. Basically you can't tell if the QR code is being displayed by the legitimate site or another site which is proxying the legitimate site. WebAuthn integrates with the browser itself, and both does per-site keys and identifies the site in its cryptographic response. You would need to compromise the site or infrastructural pieces like DNS and TLS to break WebAuthn's phishing protections. FWIW, Mutual TLS and Kerberos are the other two widely known systems here, with slightly better phishing protections because they operate below the "XSS" layer of modern browsers. However, that also means they require infrastructure investment, and are generally impractical to deploy outside environments with device management. See also https://krebsonsecurity.com/2018/07/google-security-keys-neutralized-employee-phishing/ https://krebsonsecurity.com/2018/07/google-security-keys-neu...