SQRL: Secure Quick Reliable Login
grc.com
grc.com
In the five years this has been "under development" (!!!), FIDO and WebAuthn have made serious progress, providing a broadly-supported standards-based approach with native browser support and which addresses a more comprehensive threat model, including phishing and local user verification.
I've found this doc on the subject https://www.grc.com/sqrl/phishing.htm
> To mount a phishing attack against SQRL, a fraudulent website would need to first open a valid login session with the authentic website it plans to spoof. From the valid site's login page it would obtain a “fresh” and valid SQRL link URL. The fraudulent site would then present a spoofed login page containing the authentic website's valid SQRL code. When the SQRL application is used to login, they are actually logging in to the session that was originally initiated by the phishing site. The phishing site then completes the login and can impersonate the user for that login session.
If you read on further it does explain how SQRL can mitigate this:
- Because the request from the SQRL client will not match the request from the phishing site the original website will be able to see that and reject the login. Keep in mind the SQRL login request is signed by the original site so can't spoof the payload/qr code the user clicks/scans
More specifically:
SQRL can prevent phishing if: - The remote server limits sign-ins to what Gibson calls the "same device" mode (i.e., the SQRL client and the browser have the same IP) - Attackers cannot spoof the victim's IP address (so excluding the case where the user has a malicious MITM at the IP or DNS layer, or where the attacker and victim are both behind the same NAT)
Theses are modestly valuable properties but are limited in two ways:
1. SQRL is likely not very useful if it's limited to same-device authenticators. If you have to have some credential on the device on which you are currently signing in, you may as well use TLS client certificates; they provide strictly greater security than SQRL while having the same usability. (In fact, a modern password manager—which, unlike SQRL, provides HTTP origin validation before prefilling a password—provides greater security with the same usability!)
2. FIDO provides strictly better security, both by supporting separate authenticator devices and by actually cryptographically verifying the identity of the relying party (the remote server). Bypassing the same-IP thing, as I noted above, is well within the realm of possibility.
At the risk of violating my personal "don't say mean things about people on HN" rule:
Gibson is at best an incurious hobbyist—unwilling to expend the energy to understand what else is happening in the field and, with that understanding, collaborate with open standards-based efforts to improve them—and is, at worst, a charlatan, promoting snake oil for some reason I cannot fathom.
I used to think he was the latter—selling subscriptions to "SpinRite" to gullible rubes who wanted to free their magnetic hard disks of gremlins—but I increasingly believe the former. Nonetheless, his ideas are ill informed and retrograde.
I agree with your first points around SQRL, it's an interesting concept but in the long run the industry has solved the problem eventually and possibly better. Also keeping one sqrl identity is a slog to say the least.
On the latter point, I feel like it's a mixed bag, SpinRite honestly works (and yes I've tried other tools), if you haven't been in the unlucky spot of a dead drive then I understand how SpinRite can seem a little snake oil like.
Having said that there is a big "not invented here/me syndrome" and I do wish he would participate in the open source community as a whole more, it might make him more aware of what is happening within the software community more.
I just reread it, I should do a bit of grammar linting in the future.
Indeed, exporting key information between browsers or devices are out of scope, causing browser makers to recommend never making WebAuthn log-in the only log-in mechanism, and allow passwords as fallback[0] (not really a replacement for passwords then).
Additionally, it is more complex for website operators to set up.
I know it can be done, though, and with an amazing UX as simple as clicking “login” on the chrome, and a simpler implementation for website owners.
I tried my hand at a protocol that does that[1]. I would love to see browsers do something with that UX. But ultimately, browsers hold the cards; whatever ships wins.
I believe that whatever path we have, this UX will eventually be the one users experience; I’d just like to have it happen within five rather than ten years.
[0]: https://developer.apple.com/videos/play/wwdc2020/10670/
[1]: https://espadrine.github.io/blog/posts/webidentity.html
FWIW, in terms of difficulty setting up, I suspect most developers use libraries from people like Okta and Firebase, so the underlying implementation may not be the big differentiator.
There are certainly great examples of non-standards-based approaches beating out the cumbersome/designed-by-committee standard, but they're more common in cases where there are no significant compatibility challenges standing in the way of adoption. For example, any given developer can adopt JSON internally instead of XML, and at some point it reaches critical mass and everyone is using it, including for interchange.
In comparison, SQRL isn't useful until it's widely adopted, and because it's not a standard approach with built-in support on any major platform, nobody is going to use it.
I have been thinking about the particular issue migrating identity too.
My thoughts are mostly around additional keys. Realistically, you have more than one device. You could associate (some or all of) them with an account. This, to me, feels like it's more inline with key based auth.
My other thought was something like the list of codes you have with other 2FA solutions.
I don't think we will ever eliminate passwords in the sense that a person will never need a password ever again, but I think the solutions above definitely get us to the point where we literally never need to share a password.
Ah, not exactly. I saw it a something that could become a draft standard. That said, the test vectors do come from a program that implements it by hand[0].
I assume we could write one that would implement it for the command line (say, for cURL), but the design is really meant to be implemented by browsers.
> You could associate (some or all of) them with an account
Yes. In this instance, the account is the browser’s Sync system, which synchronizes between devices.
> I don't think we will ever eliminate passwords in the sense that a person will never need a password ever again
My belief is: we should only ask each individual to only remember a single password throughout their life, so that it can be strong enough to outlast them[1].
[0]: https://github.com/espadrine/espadrine.github.com/blob/maste...
[1]: https://espadrine.github.io/blog/posts/memorable-passwords.h...
However it's very questionable regarding the per device security.
Keep in mind a lot of people manage more and more of their life through their devices so more security is being pushed on to individual devices, however 3rd party websites and services have little to no oversight that they are actually doing the correct job and keeping peoples data secure.
Just look at https://haveibeenpwned.com/ for a vague idea of how bad security is still handled by service providers.