Skip to Content

I wanted to write a quick post to draw your attention to SQRL – pronounced “Squirrel”, short for Secure QR Login.

Steve Gibson from the Gibson Research Corporation (GRC) has come up with SQRL as a potential solution of the ongoing problems associated with using user names and passwords to authenticate to web sites. We have all seen lots of stories in the last couple of years of large web sites being hacked and having their users credentials stolen – some have been encrypted others not, either way it’s not a good thing.

If you add to this that many people will use the same password (usually not a strong password either) on different sites and even more commonly people will use the same user id on multiple sites (e.g. your email address) there are lots of issues with good old username/password authentication techniques that need to be improved upon.

In my opinion from what I’ve seen and heard SQRL seems to go a long way to fixing many of the short comings of existing approaches. From the end users point of view it appears to work almost like magic. By using your smartphone you can scan a QR code from a website and “hey presto” you are automatically logged on.

SQRL1.png

Screen capture from GRC SQL main page

From a security perspective it is far more secure than traditional username/password techniques and has a number of added advantages too such as out of band authentication (e.g. via your smartphone) and complete anonymity (if you want it).

I am not going to go into the details of SQRL here. Steve does a great job of that on his GRC pages, but I’d encourage you to go and take a look there and then listen to the Security Now podcast where Steve introduces SQRL. Here’s the abridged version for the time poor among us:

It took me a few listens and a bit of reading the site to get my head around it, I am no security or crypto expert (it’s more of a hobby for me) but I think this is very promising (and pretty cool too). The next step for SQRL is to gain adoption. I want to raise awareness of SQRL  in the SAP security community  here on SCN by writing this post.

I’d love to hear your thoughts in the comments below. What about an SAP ABAP or JAVA server side implementation of SQRL? (DemoJam entry anyone!) 😎

“SQRL – you’d be nuts not to use it!”

😀

To report this post you need to login first.

11 Comments

You must be Logged on to comment or reply to a post.

    1. Simon Kemp Post author

      Yes Jason I agree it is a big mess currently. I use a password manager tool that generates random and strong passwords for me and manages them – that way I don’t ever use the same password twice, but still it is not ideal.

      SQRL appears to get rid of this entirely, in fact it reduces it down to needing only one good strong password to protect your unique SQRL private key – even I can manage to remember one good strong long password (I hope) 🙂

      I am also interested to hear what people think of the user experience. I feel like it might take people a while to get used to it. Just pointing your phone at the QR code and then being logged on might feel a bit strange to start with – I think the alternative of having a SQRL client running on your PC and clicking the QR code image will seem move intuitive initially but I love the way you can use your phone if you are not using a PC you trust.

      Thanks for your comment.

      Simon

      (0) 
    1. Tom Van Doorslaer

      Not a stupid question at all. That was the first thing I thought when reading “By using your smartphone you can scan a QR code from a website and “hey presto” you are automatically logged on

      I once had a similar thought: using the QR-code as a means to identify a person (though authentication would still be with a pin-code or the likes)

      http://scn.sap.com/community/technology-innovation/blog/2012/04/11/the-access-badge–solution-for-enterprise-security

      This seems to work the other way around. In stead of having a static QR code for identification, you get a dynamic QR code, tied to your mobile which authenticates you for that specific session on a desktop/laptop/whatever, because the phone is supposed to be yours.

      (0) 
    2. Simon Kemp Post author

      Hi Steve (and Tom),

      Not a stupid question at all 😀 … in fact it is one of the scenarios that Steve describes on the main page https://www.grc.com/sqrl/sqrl.htm nearly at the bottom of the page in the “Three ways to go… Smartphone optional” section.

      You can read it there, but to summarize if you are viewing the logon page on a phone you can simply tap the QR code and that would launch the SQRL app on the device and away you go as normal (as if you scanned the code off the screen). There will be a custom sqrl:// URL scheme registered on the device so it knows to launch the SQRL app when it encounters such a URL scheme. This would work the same on a laptop/PC if you didn’t have or didn’t want to use your smartphone. A bit like a “mailto:” or “tel:” link.

      Thanks for joining the conversation on this.

      Simon

      (0) 
      1. Steve Rumsby

        Ah. That’s quite clever.

        Now we just need to talk about the MITM attack. Not that this is any more vulnerable, technically, than a regular password. But people might think it is and not be so careful, maybe. It is a shame that hasn’t been addressed. I can see ways to do it if the QR code if processed on the PC, but not if done by a smartphone.

        The tricky part of all this is going to be getting online services to use it…

        (0) 
        1. Simon Kemp Post author

          Hi Steve,

          I don’t think the Man in the Middle (MitM) attack is really an issue. MitM is protected against by using SSL just like it is now for username/password scenarios. I don’t see why SQRL would be any more susceptible to this type of attack.

          Would be interested for you to elaborate on your fears related to MitM maybe Chris Paine would like to share his concern too that he mentioned via Twitter. Here we have more than 140 characters to debate it 😀

          Thanks

          Simon


          (0) 
          1. Steve Rumsby

            I agree it is no more susceptible than the current password mechanisms, but because it seems more secure people will be less careful about checking. Gatekeeper syndrome (The Net reference:-)

            Steve.

            (0) 
          2. Chris Paine

            Hi Simon,

            I think this is a pretty cool concept (I’m actually using a very similar concept as part of the extension to the timesheeting development that Jo and I built).

            However, the reason I mentioned the MitM issue is that there is no way to validate that the  code is coming from the site that you think it is. (yes the redirection will be to the mentioned site, but given how easily people are phished I’m not sure this is enough.) Ideally the QR code should be authenticating itself to you at the same time that you are authenticating yourself to it.

            If you look at the way OAuth works, both parties need to exchange tokens so that they can trust that who they say there are is who they are. In this scenario, you are just informing the site embedded in the QR code that you are who you say you are, but no guarantees about who they are. Admittedly this is the same in a user/password MitM attack – you have no additional info to prove that the site you’re speaking to is the right one. And at least in this case there is a reasonable chance that you could foil the MitM attack because hopefully one of your channels of comms is out of band of the other (although in reality, it’s likely you’re using the same network path for both communications.) What would be cool is if the QR code was signed by the website’s security certification – that would mean we could verify (if we trust the root cert authority) that the site we are validating to is actually the one we are logging into.

            The other thing I don’t like is the storing of passwords on devices – basically if you lose the device you’re in trouble (as far as I understand).

            I prefer the use of dual factor authentication with simple non-stored passwords, perhaps SQRL could be a second factor – that would be cool.

            Personally, I think having a highly secured trusted sign-on (i.e. gmail using 2 factor auth) and then using OAuth to sign into another site is an easier and more secure solution. It’s also an awful lot more convenient. But it certainly doesn’t address all the cool things that this (SQRL) solution does (like avoiding keyloggers on public PC, anonymous logins, etc.) However, I would wonder how many times I would be logging onto a site on a public PC if I had my smartphone in my pocket, and I’m not sure that any web interaction these days is truly anonymous, perhaps it’s better not to give the false impression that it is.

            So whilst I think it is a cool solution, I don’t think it’s the solution to all our password woes just yet.

            Cheers,

            Chris

            (0) 
            1. Simon Kemp Post author

              Hi Chris,

              Steve Gibson goes into the details of this attack in much more detail here

              https://www.grc.com/sqrl/phishing.htm

              The pages are currently being updated quite actively so I hadn’t see this until now.

              In that description he makes the case for SQRL actually being less susceptible to phishing attacks than standard username/password and makes the point that the malicious site would only ever get a single access to your account (not ongoing as in a typical username and password phishing exploit).

              He also describes a method of IP verification which defeats this attack (in some cases).

              In any case I thought you’d be interested.

              Whether Google with 2 factor + OAuth is more secure… humm… would need to think on that – certainly dual factor would add extra security I think.

              Cheers,

              Simon

              (0) 
              1. Steve Rumsby

                He talks on that page about the scenario where the authentication client is running on the same machine as the browser. As I said above, that’s easier to deal with. It doesn’t really help with the original “capture a QR code on your mobile” scenario that’s so appealing.

                But even being able to thwart such attacks from a regular PC is a good thing!

                Steve.

                (0) 

Leave a Reply