
SQRL: Secure Quick Reliable Login - BerislavLopac
https://www.grc.com/sqrl/sqrl.htm
======
md_
Gibson has been hawking this for years. Skipping over some details, the
biggest issue with it is that it's phishable, so it fails to address the
single biggest threat most users face.

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.

~~~
espadrine
I love WebAuthn for 2FA, but I feel like it will struggle to go from 2FA
system to primary login (as full replacement for passwords).

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/](https://developer.apple.com/videos/play/wwdc2020/10670/)

[1]:
[https://espadrine.github.io/blog/posts/webidentity.html](https://espadrine.github.io/blog/posts/webidentity.html)

~~~
md_
I have mixed feelings about key export. :) That is indeed a fair criticism.

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.

~~~
espadrine
Yes! Identity is at this weird place where the goal of the solution (to have
the same thing work everywhere instead of the status quo) cannot gain adoption
organically, you need browser buy-in first. Which nowadays basically mean to
convince Adam Langley.

------
unknown000
Looks like overcomplicated authentication with TLS client certificate, for
some reason brought on application level. Websites now store only public data
indeed, but confidential data is pushed to client devices, which may be even
more vulnerable than the original service (and often are). On the other hand,
if implemented correctly, such approach may be more flexible than web server
settings.

~~~
botto
It is complicated for sure and I think one of the problems is currently the
clients for SQRL are pretty bad (I've tried them all, maybe I'm just picky)

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/](https://haveibeenpwned.com/) for a
vague idea of how bad security is still handled by service providers.

