SQRL wan't wrong, it was early | Hacker News Reader

SQRL wan't wrong, it was early

sjg.io

38 pointssimonjgreen9 comments

SQRL has the same weakness as passkeys: secrets on device are too easily lost, gatekeepers too greedy to solve that without taking away user sovereignty, and people don't understand it.

IMO both solutions are a lost cause. Hopefully I'm just cynical and something can be worked out.

Discord and Steam have a user login flow that is very similar to what SQRL was aiming for, including a QR code alongside the username/password fields. While it's a closed implementation of a different system, I think of SQRL every time I use it.

I might be biased, I used the PPP Pam module on linux for years, until I moved to TOTP, and then eventually to pubkey-only.

It was too early, but also lingered in development for far too long. It also never had the proper server-side implementations, so it could feel like a solution in search of a problem.

That said, the design is far more advanced than the rolling disaster which is Passkey and it is much better suited for small Yubikey-type devices, where you could easily have unlimited site support. It also had intrinsic portability and advanced real-world security considerations, such as an attestation that instructed a server to disable weaker authentication methods, such as email or SMS (which is also a customer support disaster, but still...).

Ultimately, SQRL is an object lesson that the best technical design doesn't always win - it needs the right timing and robust community/corporate support.

Edit: Also, the (client) reference implementation was written in x86 assembly language for Windows. So I'd say the timing, support, and portability are all reasons for the lack of adoption.

The current idea of passwordless seems to be "give me your email and put in the 6 digits i send you" - who ever pushes this absurdity, I hope you have an itch and short arms.

If you can reset your password via email you already are in the same security level that with receiving that 6 digit code.

I personally prefer using that system better than passkeys, at least with the email code I understand the security implications.

The security implications are one thing, but another issue to me with email codes is that you now have to wait for an email to arrive. At worst this can take a few minutes, at which point I'm no longer interested in logging in, unless it was for something I absolutely have to do. At best I have to open my mail client or log in to the webmail, while with a password or passkey all I need is Keepass running.

Or we hope his armpit is infested with fleas from a thousand imaginary camels.

Another perspective on this is that coordination is the hardest problem to solve in deploying technology that depends on cooperation between different parties. It takes a few of the big centralized players to agree to put their weight behind it.

The tech is actually easier.

eh. it’s cool,

but compared to FIDO which existed when it was made, it’s pretty obviously “wrong”.

Reply on news.ycombinator.com