> 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.
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-neu...
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.
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.
If it's a standard "lost password" flow, in which case it still suffers from the same weaknesses of the lost password flow?
Honestly saying that part out loud, one of the annoying parts of it all now is that the credential store for WebAuthn is now effectively per-application, not per-user. So you need "number-of-browsers * number-of-devices" different registrations, which is basically annoying enough to mean I still use 1Password. In some fancy world, the actual credential store could be some kind of persistent, per-user system service provided to any application, and they would all share these credentials. Sort of like Apple Keychain on steroids, basically, but it needs to work everywhere, on all platforms, and be adopted consistently by applications.
It's only works in the Apple ecosystem currently and is only a technical preview, but it's a cool idea to reduce the number of registrations you have to do and reduce the chance of getting locked out of websites by losing your WebAuthn key.
There is work being done to try to create a realistically usable cross-device (e.g. mobile phone as authenticator to my desktop) support leveraging Bluetooth LE. One could hope for a future where say an iPhone with these WebAuthn "PassKeys" (as Apple branded them) could be used to authenticate with a Windows laptop.
There are also draft features which would allow a site to detect you are going cross-platform, and offer to add an additional local Windows Hello mechanism to streamline the process in the future.
Some systems like Google Advanced Protection Program specifically don't really have alternate means of authentication or a recovery flow.
If you register multiple authenticators, you can do a break-the-glass/open-the-safe recovery, but this assumes you remembered to register all authenticators to all sites.
There is a proposal to support backup keys via what might be referred to a cryptographic introduction. My primary key can include additional cryptographic data, and if I lose my primary key my backup key can prove that it was the key that was previously mentioned.
There is a tech preview by Apple for PassKeys, which is a WebAuthn authenticator which isn't represented by a single piece of hardware but across all the hardware on your Apple account. This reduces the need (or I suppose, increases the trauma) needed to get to an account recovery event.
Yes, if they've got a "lost device" flow that bad guys can easily defeat then, bad guys can easily defeat it.
There's a reason passwords haven't been usurped yet. It's because these fancy new ideas come with an entire new set of their own problems. These problems are worse than what we deal with for passwords.
I've only seen WebAuthn and Touch ID replace a one-time code either sent via text or looked up in Google Authenticator. I have one Yubikey for each laptop I own, and also use Touch ID / Face ID on iOS with whatever site will allow, but it's always a second factor, not a password replacement.
The weird thing is that I also use a password manager on mobile (KeePassium), and I have it configured to unlock with Face ID to autofill my usernames and passwords. So on some sites I actually do have "passwordless" log in, but in a round about way.
Not sure whether I should be eager to drop passwords entirely, whether this WebAuthn + password manager flow is the end game, or whether I should go change the config to require my master password manager password for every log in.
Passwords are necessary if there is no guaranteed identity provider of last resort to fall back to, as the email|username/password|secret credential pair is then the identity.
These devices will also become the ones responsible for setting up the same login on other devices. These would work in a way similar to, for example, how Apple or Okta handle two factor authentication by sending a push notification to existing devices registered to the account.
Since most people wouldn’t have a Yubikey (or multiple Yubikeys for backups) and since most people own one smartphone, the fallback for account recovery — when their smartphone breaks or is lost — would be the weakest link.
Yubikeys are a pita as well. I have an NFC one I use for authentication on my laptop, and a second in case I lose it. Registering both tokens on some websites is just not possible, and remembering to register both, at sites where it is, is easily forgotten.
The problem with biometrics is they're persistent where you don't want them to be (you can't change them) and not where you do (after you wipe your phone, or buy a new one)
I recently wiped and reinstalled my phone, and reinstalled about 10 bank/finance/credit card apps. Not one of them requires much more than some lame security questions, card details and SMS verification to get up and running. Fingerprint login is just a convenience.
Passwords will still be a thing in 50 years.
Biometric identification is only an "improvement" for political police across the globe: it makes people ok to give their fingerprints away, and opens new (back)doors into people's devices. Fingerprint readers are Stalin's dreams come true.
If it is all tied back to a single private key / pubic verified identity, then does it become easy to cross reference every account someone holds a la keybase verificaiton?
- how easily are they grouped together:
** by your devices
** by your account nameS
** by your end-apps
- How easily removed (a central management page that offers automatic revocation)
** by excess usage
** by excess financial amount
** by strange location
- How easily stolen
** Face ID imprints
** Something you know
- How easily blocked by something you have.
** Your PC machine ID
** key fobs (Yubikey)
** your IP address
Would be great to hear stories from people who have put the equipment "through its paces" so to say :)
Unlike Yubikey you can import an externally generated seed so you can replace a Trezor if it gets lost/breaks without registering multiple devices.
To be able to delegate authorization in this scenario, you're first going to have to prove who you are to GitHub. Thats where you'd use WebAuthn.
They basically solve separate problems.
Now, when you are doing OpenID Connect (which adds Authentication), this becomes more of a question like - do I have users sign in with their Github account to my site, or do I just support all that directly via WebAuthn. Quite a bit more overlap. *
However, its not that uncommon for sites to support multiple ways to log in. Having a cloud-based login and a local login might prevent some random event causing the user to completely lose the ability to log in.
* Note I took some license here, since Github built their own thing rather than using OpenID Connect.