Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

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.

share|improve this question
    
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 '13 at 19:37

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.

share|improve this answer
    
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 '13 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 '13 at 17:11

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.