The problem with SQRL

I just listened to Steve Gibson’s SQRL (Secure QR Login) authentication scheme. I’m not a cryptographer, but I see some minor issues. I’d appreciate people correcting me and educating me. Here are a few issues I have with the authentication scheme. But to be brief, I think there are problems. [Added note: This post was based on the October 16th podcast where Steve first described SQR, and it’s benefits. The transcript is here.  Steve has refined and further documented SQRL since then. ]

No email addresses are used

A big advantage of SQRL, according to Steve, is that  SQRL doesn’t use email, which is great for the user who wishes to remain confidential. Of course, the IP address and other browser details can be captured, so using SQRL doesn’t provide true anonymity.

However, many sites require an email contact for many reasons:

  1. They want the marketing capability. And the email allows them to send you promotional material.
  2. They want to have a way to asynchronously contact their members in case of an emergency.
  3. They want to prevent automated systems, and spambots, from generating millions of accounts for their site.

Personally, I like the ability to log onto a site without an email. But I’m not paying for the web site. The paying owners have final say. So the first issue is getting the web sites to want to provide this feature. And not all sites will want to offer accounts without email addresses.

[Update – I elaborated on this in a newer post. ]

SCRYPT is recommended on smartphones for “deep encryption”

Steve suggests that the master secret key is stored on your smartphone, and that “deep encryption” is used to encode this secret key when exporting it. He suggests that scrypt be used, and that it takes “60 seconds” on a smartphone to do the encryption.

Scrypt is memory intensive, and many smart phones have limited RAM. Steve says “You could say we want a megabyte.” The problem is that while it might take a memory-limited smartphone 60 seconds  to perform th that can perform the same e algorithm, one can get a server with 128GB of RAM that can perform a brute-force attack as a much higher rate.If it’s too memory intensive for a server with huge RAM, a smart phone won’t have the RAM to do the same algorithm in a reasonable amount of time.

It’s not “Out of Band” and has nothing to do with a camera

Steve mis-spoke when he suggested SQRL was “out of band”. The podcast also says it requires adevice with a camera and an Internet connection.But this is wrong. The camera has nothing to do with it.   You can’t use the smart phone to take a picture of itself – unless you use a mirror.  You are doing a screen capture/screen grab, and the camera is not, and never was involved. It just confuses the issue.

SQRL:// is a bad idea

Steve suggest that a special URL tag such as SQRL:// might be used. This is not a good idea.

First of all, we know we want to have a HTTPS:// URL to log onto a web site. Anything else provides an opportunity for a man-in-the-middle attack. You don’t want to perform part of an authentication with SQRL:// and a second part with HTTPS://. The two sessions would require the passing of cryptographic state between them, and allowing a moment of interception just provides an opportunity for something bad to happen. It’s better to start with HTTPS:// and use the single session.

There is no reason to use a QR code

The QR code allows you to store the info on a piece of paper, and lets you “import” it back into a computer with a camera. And it provides a easy way to see that the web site offers SQRL login. But realistically, there is no reason that QR codes be used on the web page. As I said – the camera is never used during the authentication process.

Steve’s proposal uses the QR code to provide a string of numbers. The same information can be provided in the HTTP header. This simplifies the process because a GIF does not need to be converted into an ASCII string.

An ASCII string is preferred because (a) this can be provided on a https: page, which can be authenticated, and (b) a browser can automatically log someone onto a web site with a browser plug-in, if they chose to.

SQRL should not rely on a human to authenticate a domain

Hackers can create web sites that look very much like a legitimate site. They can change a “l” into a “1” and some fonts won’t show a difference. An “o” can be changed to an “0” or using accents in domain name. An example is  totå vs

Or else they can create a host with a domain name that is so long, that it will be truncated, and the truncated name looks legitimate.

The only way this authentication system work is if the authentication process checks the domain name from a whitelist of approved domains – automatically.  A human can be fooled.

SQRL cannot detect DNS poisoning

SQRL cannot by itself be used to detect a malicious site using DNS poisoning. A hacker can inject a bogus IP address into a DNS server, and trick a user to loging onto a bogus site.  Unless Secure DNS is used, SQRL will not detect interception.

SQRL cannot not detect expired domains

A SQRL code can be years old. SQRL has no way to detect this problem, because there is no way to expire the web site unless some external clock is used.  HTTPS/SSL does detect this problem – because expired certificates can be detected, and the client can refuse to connect which this occurs.

Also – someone may forget to renew their domain registration, and someone else can swoop in and set up a replacement domain. SQRL cannot detect this. HTTPS can.

HTTPS can be used for mutual authentication.

I’ve explained why SQRL cannot authenticate a web site. HTTPS addresses these issues, and is superior in all respects – except that it doesn’t provide frictionless authentication. However – it could if the web site owners choose to use this.

HTTPS can use mutual authentication – with client-side certificates.  The main reason this isn’t often done is that it’s a hassle to installed a signed certificate into a client, and having multiple web sites agree to the same certificate authority.

But if the web site allows self-signed certificates as part of the authentication process (in stead of a certificate signed by a third party), then HTTPS provides all of the features of SQRL – and none of the problems. And this uses a well-studied protocol.

In conclusion

If a web site owner configures their web site to perform mutual authentication and allow self-signed certificates, then as far as I can tell, this has all of the advantages of SQRL, and none of the disadvantages.

So I don’t see any reason to use SQRL.

This entry was posted in Hacking, Security, Technology and tagged . Bookmark the permalink.

19 Responses to The problem with SQRL

  1. Pingback: Some problems with SQRL | Rocketboom

  2. Pingback: Some problems with SQRL | Enjoying The Moment

  3. Your premise that HTTPS addresses anything is flawed… MITM attacks can occur even on HTTPS if the attacker has leverage over the CA that’s signed your HTTPS certificate. If you’re assuming that the attacker has the capabilities of poisoning DNS, it’s not an unreasonable assumption that they could have the ability to obtain a certificate for HTTPS as well. Especially if that attacker is a hostile government (who could compel the CA to provide them with a certificate for the target website)… or really anyone with leverage over a signing authority that’s trusted by your browser.

    • Rogan Dawes says:

      This is not true. A *successful* MITM would require that the attacker can generate a server certificate that is accepted by the client (i.e. signed by *any* CA trusted by the client), unless the client is doing certificate pinning.
      However it would *also* require that the attacker have a copy of the private key and certificate used by the “victim”, otherwise the attacker would not be able to establish a mutually authenticated connection with the true server. And to get that, you’d have to compromise the client’s computer to the extent that you might as well just copy off the keys, and use them directly to authenticate to the server.

      • grymoire says:

        WHen I wrote the blog post, which was immediately after his first podcast on the subject, SQRL had NO WAY to authenticate the server. Steve has since added this feature. But without server authetication, SQRL had no protection from a bogus server masquerading as the legitimate site.

        HTTPS is a different issue, and at the time Steve never mentioned how HTTPS and SQRL worked together. He even mentioned using the SQRL:// URL as a way to log onto a site. He also described scanning the QR code with the camera on your smart phone, which as I pointed out had to be a QR code on ANOTHER COMPUTER!!!

  4. Pingback: The SQRL Code Blog

  5. Sander says:

    Many of these problems have come up on the podcast, I would recommend to listen to the last 2 Security Now! podcasts and view some of the discussions on the grc SQRL news group.

    The following is my understanding (as a developer, not particularly specialised in security):

    • SQRL has no friction, you can use SQRL to repeatedly identify the same visitor, then you can ask them for an email address if you want to store one.
    • He said SCRYPT would scale (ie take 60 seconds to encrypt the master key, regardless of the power of the device) therefore there is not the brute force problem?
    • It’s out of band? The device you use to login to a site with (desktop) is not the device that does the login (smartphone ideally) with a different network connection.
    • Why can’t you use SQRL as a different name for HTTPS? That part is just a proposal so not a problem with SQRL.
    • See out of band, that’s a reason to use a smartphone.
    • Can’t see why an application can’t remember the domains that have been logged into, and prompt to confirm if the domain is new?.
    • Re dns poisioning, this is not any different to user/ password login form therefore not a problem of SQRL as a replacement of user/password forms.
    • The SQRL masterkey generates a public/private pair, which can expiry (think this is part of the standard already).
    • Again SQRL or HTTPS links is not a problem with the protocol?

    Hope that clarifies things. Again I don’t claim to have a correct/full understanding of SQRL myself.

  6. Jonatan Werpers says:

    You have some good points but there are some thing I would like to comment on.

    Regarding your comment about there being no email address involved:
    There is nothing stopping a site owner from still requiring you to provide a email address before they let you use their service. They may then store the email address and attach it to the identity that you provided them through SQRL.

    Regarding your comment about sqrl://
    I think you have misunderstood where sqrl:// would be used. It’s not a protocol used for communication between the site and your sqrl client. It’s only there to tell the operating system(your phone or your computer) that is receiving the sqrl link what to do with it. Of course when your sqrl client connects back to the website it is using a secure https connection.

    Something to add to your list of flaws would be the fact that if you ever lost control over your sqrl-identity it would be kind of a nightmare. Of course this problem exists with regular passwords too, but I think the way sqrl works makes the consequences even more dire.

  7. Ernie says:

    The 3 keys to the security are something you have, something you know and something you are. Single factor is simply something you know in most cases. What SQRL does is take it to 2 or (possibly in some cases) 3 factor authentication. At a minimum it is 2 factor in that you know your password and you have your phone. In the case of an iPhone 5s if you’re using the fingerprint scanner you now have 3 factor authentication if you set it up properly (and the implementations will be critical). If you take it down to the level of everything on a single device you are weakening the security provided (though with the iPhone 5s you are still potentially multi factor). The best scenario is that SQRL and the phone are used to authenticate you to another device (your computer or your iPad lets say) with an iPhone 5s right now being the ultimate with this method for security (more will follow quickly I’m sure).

    That should also explain why the QR codes are in fact needed. Without them I can NEVER securely log into anything I don’t own. At work they may be listening, at the library I assume someone is listening. Authentication within those realms is never secure. By using the QR code you transfer the authentication to your mobile device which is within your control and much more difficult to attack than the average wifi network. Minus that SQRL is only a semi secure solution for devices completely within your control and even then it’s limited by the security (or lack of security) of your network. There are plenty of limited solutions already and SQRL is designed to be much more than that. I will add that this also addresses your statement that cameras have nothing to do with it. They have everything to do with it as they are the medium that decouples you from the insecure environment. Eliminate the camera and the whole things doesn’t do what its intended to do.

    One very legit problem that you mention is that some sights actually require to know who you really are. Not just the sites that want your email address (and they won’t be giving that up easy) but Amazon and EBay etc that truly NEED to know who you are. It’s hard to ship something to a completely anonymous person. That is a legit problem (and one of the things that I am working on myself actually).

    The idea of using sqrl:// isn’t the problem that you think it is. For starters, you assume that because you use sqrl:// instead of https:// that https is not used. While you could do that there is no reason that you would and I assume https will be used. Internet protocols are almost all stacked. TCP/IP is a stack. TCP rides on top of IP. http:// rides on top of TCP/IP and https:// rides on top of http. sqrl:// could easily ride on top of https. It’s a none issue until someone proposes a poor solution that doesn’t address the obvious need. You simply can’t assume sqrl will exists without https 11 days into the development.

    SQRL has a few issues that need to be addressed but the meat of it will work and none of these issues are without solutions. It may not end up quite as independent as Gibson would prefer and there will definitely need to be a non anonymous implementation that has a good chance of being the primary implementation in the end (Gibson seems hung up on anonymous) but there are absolutely no show stoppers for SQRL at the moment. It can work and it can accomplish most of what Gibson set out to accomplish.

  8. Abhi Beckert says:

    If you have a server with 128GB of RAM, and require 1MB to perform the SCRYPT generation, that means you can perform 128,000 simultaneous password guesses.

    A proper brute force attack would require something like 600,000,000,000 simultaneous guesses. This means 600 Petabytes of RAM.

    At current prices for server grade RAM, it would cost you about $33,000,000,000 to buy the RAM to perform a brute force attack on someone’s SQRL password. You would also have to buy enough servers to put all of that RAM in. And you would have to somehow acquire the user’s encrypted private key, which is supposed to be kept somewhere that is difficult to get hold of.

  9. Nick Donnelly says:

    You should have researched this better before commenting.

    Listen to the podcast episodes first at least.

  10. I want to address the one valid point I see here: SCrypt strength on memory limited devices is a real concern! My principal contributions to this project are to address that issue.

    Memory limited devices restrict the SCrypt N and r parameters which SQRL has available to it. We’ve discussed on the GRC newsgroups and several contributors helped devise attacks on the memory limited SCrypt parameters. Implementers should avoid low values of r (r=1 is potentially very bad) because of the theoretical ability to memoize results of the blockmix/salsa function inside SCrypt. With 32MB of memory available (early iPhones) the maximum N would be 2^17. This means that the offline storage hash would have a large p, which opens up the system to GPU attacks. For example if p=650 and the system has 650 cores with 32MB available to each one an “average password” with 42-bits of entropy (see SCrypt paper) could always be 50% likely to be found in 2^32 time. Practically speaking that means that if someone gets your SQRL 60-second backup then on a machine 3000x faster than your phone your average password would ONLY take 48 core-months to crack.

    This is not really acceptable for perfect security and is within an order of magnitude of practically breakable. Please use a strong password for your permanent SQRL backups!

  11. Pingback: SQRL and EMAIL – Why anonymity isn’t practical | The Grymoire

  12. Bianca Hlywa says:

    The QR code is needed to quickly transfer information from a laptop to a phone.

    [Yes – as I said, it “lets you import it back into a computer with a camera.” – Bruce]

  13. qubit says:

    More secure alternative:

  14. So, arguably SQRL is incapable of properly authenticating a website, or expose any number of targeted attacks and persistent threats. But does it have to?

    Existing technologies work well enough on the server side. PKI is a hassle and comes at a cost, but not out of proportions when seen in relation to other aspects of providing services or content on the web. You have one domain/host, you get one certificate which speaks for the authenticity of your site to thousands or millions of users. Now, TLS certainly has it’s problems, but on the whole it’s probably adequate for the intended uses.

    What we don’t have is a good way to have returning users prove their existing relation to your site, at least not without involving a third party (eg. OpenID and the more proprietary alternatives, or). Today’s most popular method of one-to-one user authentication remains a user identifier paired with a secret.

    I for one think we could do low friction, one-to-one authentication of users that does not involve a critical piece of information that not only must be kept both secret and available, but can be forgotten, misplaced or stolen. I won’t be using anything like SQRL (or OpenID) to log in to my bank accounts any time soon, but to replace the dozens of passwords I have to juggle around just to access the hundreds of forums, vendor sites, webshops, blogs and social media sites I crawl through in a typical month, I find that SQRL represents a very interesting concept.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s