I recently looked into SQRL and was intrigued by its simplicity.

At first glance it seemed reliable and its author claimed it was inherently fail-proof against phishing and MITM attacks.

But upon further reading at this stack exchange discussion I saw a comment (the 2nd reply by tylerl) that claimed it was highly susceptible to MITM.

Both line of arguments appear similar except one concludes that it is safe and the other not. As per the author authentication is happening with the correct server. So I can't to understand how MITM is possible.

Also the stack exchange reply claimed client side authenticators like LastPass prevent phishing. Wouldn't it be just as simple to have similar client side authentication in the SQRL?

A little clear up would be very helpful.

  • Note that SQRL was very volatile within the last month or so as the protocol details have been hammered out. Phishing prevention is a more recent addition which may predate most answers in that other thread. I believe a neutral re-evaluation of SQRL is in order by now, I wouldn't necessarily call the existing answers up-to-date nor very unbiased for some reason.
    – deceze
    Nov 28, 2013 at 19:37
  • TL;DR: SQRL is no more vulnerable to phishing than passwords are in the worst case (scanning a QR code), and is basically impervious to phishing in the case where you're using a SQRL client integrated with your browser. It isn't susceptible to MITM at all as long as you're using HTTPS.
    – Ajedi32
    Jun 16, 2015 at 16:32

1 Answer 1


The MITM-related issue with SQRL derives from the fact that the authentication request and response happen across two different channels, and an attacker can successfully conduct a valid authentication request/response from an invalid site. That is, an attack site could fetch an SQRL code from the correct site, and present it to the victim. The victim can authenticate against the provided request, but by doing so he'll log in the attacker instead. The lack of coordination between the browser and the phone means that you can't protect this step.

In this sense, SQRL isn't any more susceptible to phishing/MITM than passwords, and it's somewhat better in the sense that authentication has to happen online. But it's worse than existing alternatives, and that's the problem.

So, for example if your mother or boss or coworker or friend says to you: "I want to be more secure online, should I use SQRL?" Your answer must be: "No, use Lastpass and random passwords instead."

The fundamental difference here is that browser integration thwarts all phishing attacks, and since phishing is by far the most serious threat to your online safety, this should be your first priority, trumping all else. No alternative should be even considered if it doesn't protect against this threat, because it's the one you're most likely to face. If you're going to switch, switch to something that will keep you safe, not something that won't.

What of GRC's Countermasures?

GRC's first point about how SQRL codes are unique to a given site is irrelevant, and I'm not sure why he bothers to mention it. Basically he's saying that paypal.evil can't generate their own SQRL code for paypal.com. The attacker would have to fetch an authentic code from paypal.com and present it to the user. Which is exactly what they'd do.

The "Login Redirection" countermeasure is really only feasible if you're using browser integration... in which case it's completely unnecessary, since the browser can already tell whether it's at the correct site or not. If you're using SQRL with a phone as originally designed, then the "login redirection" link would have to be manually typed into the URL by someone reading it off the phone. So... that's not going to happen.

The "Action confirmation" countermeasure is a load of silliness. The idea is that you log in to the bank with SQRL, then each and every activity (including viewing sensitive data) done on the bank website would have to be manually confirmed on the cell phone. It'd be like using the bank's own cell phone app, but with added inconvenience.

The source-ip verification stuff that GRC goes into great detail about is a hack. The protection is inconsistent and incomplete, and implementation would be messy and error-prone to say the least. This is important because while it may be "better than nothing", it's not "better than the alternative"; you can actually have good security, but this isn't it.

All of this is an attempt to retrofit critical safety provisions into a system where it wasn't designed to fit. And that's really the core of the problem: the system was built to solve uncommon or nonexistent problems, while ignoring real, serious, and pressing problems. So we're taking a system that was poorly-designed to begin with and attempting to patch it to make it "professional-grade". That's kind of like taking skyscraper blueprints drawn by an auto mechanic and attempting to fix them to make something that could actually be built. The most practical and effective approach is to start over from scratch.

Could we build a secure alternative?

Of course we could. But the key to doing so is to look first at your primary usage case and threat model, and build the system accordingly. For example, SQRL was designed such that all authentication happens on your cell phone. You could retrofit the solution to allow for browser integration, but all the features and design decisions were based around the assumption that your cell phone is your identity, which is why phishing protection is so difficult.

Designing a system to address all of the most likely attack scenarios really is simple. All the necessary components exist, and all the problems have already been solved. I won't go in to the details here since this isn't the place for it, but I would wager that if you asked a dozen real security and identity experts, they'd all come up with roughly the same design.

  • If "The app issues a secure HTTPS POST query to the QR code's URL", it's unclear how your initial statement is true - paypal.evil may steal paypal.com's QR code, but it'll still send the client directly to paypal.com's site, so no MITM. paypal.evil would have to generate their own QR Code with their own link and fool the client/user into thinking that was paypal.com - which is probably easy, mind you, akin to GeoTrust's pathetic 'Verified by' images. If I'm missing something, let me know - I agree with your analysis in general, but that first bit doesn't sit right.
    – gowenfawr
    Nov 29, 2013 at 13:20
  • 1
    @gowenfawr The QR code is an image. There's not mechanism for an image to send a browser anywhere. The image is interpreted by a phone which communicates only with the server (not with the browser), so it can't send the browser anywhere either. SQRL requires only that the victim see the QR code. Nothing else, not HTTPS or form urls or anything like that can enter in to the discussion. SQRL is fairly unique in this regard.
    – tylerl
    Nov 29, 2013 at 17:11
  • @tylerl - the QR is the same as "form url" it is just text encoded as an image. Thus being an image can't make the process any less secure. as gewenfawr says a website can't use there URL to get access so there is no MITM possible. So you have authenticated to paypal.evil. Since you don't have a password with SQRL there no information paypal.evil could extract that would help a man in the middle to paypal.com. They might be able to fool you into putting in other personal information -- but that is not MITM.
    – Hogan
    Feb 24, 2015 at 19:49
  • 1
    But this can easily be avoided by the client. Saying this is a fault of the protocol is the same as saying HTML protocol is bad because fishing attacks can exist on them too.
    – Hogan
    Feb 27, 2015 at 15:19
  • 1
    Not sure I agree with that. I think SQRL is about improving (but not perfecting) the authentication "problem". Part of that involves security and part of that involves removing barriers and increasing convenience without sacrificing security. The phishing problem exists with the current model and exists with the SQRL model. Some things are better with the SQRL model.
    – Hogan
    Feb 27, 2015 at 15:35

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .