Rendered at 22:47:26 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
paulryanrogers 20 hours ago [-]
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.
breput 20 hours ago [-]
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.
kj4ips 21 hours ago [-]
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.
TabTwo 10 hours ago [-]
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.
yomismoaqui 9 hours ago [-]
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.
Ghoelian 8 hours ago [-]
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.
egberts1 8 hours ago [-]
Or we hope his armpit is infested with fleas from a thousand imaginary camels.
vlmutolo 8 hours ago [-]
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.
DANmode 20 hours ago [-]
eh. it’s cool,
but compared to FIDO which existed when it was made, it’s pretty obviously “wrong”.
IMO both solutions are a lost cause. Hopefully I'm just cynical and something can be worked out.
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.
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.
I personally prefer using that system better than passkeys, at least with the email code I understand the security implications.
The tech is actually easier.
but compared to FIDO which existed when it was made, it’s pretty obviously “wrong”.