Hacker News new | past | comments | ask | show | jobs | submit login

The GRC page you referenced describes one potential scenario:

> 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.




Nice quote out of context there.

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


High level point: the link https://www.grc.com/sqrl/phishing.htm acknowledges that phishing is out of scope of SQRL.

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.


Just as a preamble, I listen to his podcast and have for years, so I'm probably biased to some degree.

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.


Excellent reply, and it puts him in more context than I have. Thanks!


Thank you :)

I just reread it, I should do a bit of grammar linting in the future.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: