How SQRL may improve the website login and authentication process

Martin Brinkmann
Oct 9, 2013

If you want to sign in on a website on today's Internet, you have to supply a username and password to do so. It does not really matter if you type the login details in manually, or if you are using a password manager to do that for you.

One of the problems associated with the authentication process is that the data is not linked to a specific person. If someone else gets hold of your username and password, they will be able to log in on most Internet sites without problems.

The solution that most companies seem to favor right now is to add a second layer of authentication to the process. This is called two-factor authentication, and involves the realtime generation of a code that you need to enter as a second login step before access is granted.

Introducing SQRL

SQRL (pronounced squirrel) is a new website login and authentication technology by Gibson Research Corporation. Websites that support SQRL displays a QR code on the login page that contains the website url and a long random number.

The user scans the code using the SQRL app, program or extension. The site url is displayed to the user before any other actions are taken. Without confirmation, everything stops right here.

The application produces a unique site-specific public key pair using the information and signs the URL of the site using the site-specific private key.

It then uses a secure HTTPS Post query to the site the user wants to sign in on providing it with the generated site-specific public key and the cryptographic signature.

The site uses the cryptographic signature and the site-specific public key to verify that the signature is valid for the url. This verifies that the user used the private key of the key pair to sign the url of the web service.


You may have noticed that there is no entering of usernames and passwords, or account creations involved. While it is certainly possible that websites may provide new users with opportunities to create a profile, it is by no means required to sign in using SQRL.

Other benefits of the new technology are that SQRL IDs are site-specific, which means that it is no longer possible to link a users account or login to multiple web properties. A login will only work on one site, and no other site.

Visitors are identified by their public key, a 256-bit number that is presented to a website every time it is visited. What is interesting here is that websites can identify users without knowing anything about them.

A basic example where this may come in handy is posting comments on sites. Instead of having to register an account first on many sites, users could simply use SQRL for identification to post comments on those sites.

The web server the website is hosted on only stores the public key of users using SQRL. If a server gets hacked, that is all hackers get (plus other information that users may be required to add after the first authentication).  Hackers cannot use the public key for anything, as they need access to the private key as well, which the website does not have access to either.

And since there is no keyboard input during the whole process, it takes care of all keyloggers and other recording applications that may be running on a computer system.

Last but not least, it is also a decentralized authentication option. The application you use is the key, and it runs only on your smartphone or your computer.  There is no third party involvement whatsoever, and the algorithm used is NSA & NIST-free.

The official SQRL website offers additional details (lots of them) about the technology. If you are interested in digging deeper, this is a good place to start.


Previous Post: «
Next Post: «


  1. Steve said on May 12, 2014 at 5:17 pm

    I find it hard to understand the cycle of Gibson publishing something and the blogger community going crazy about it. It seems as if the community falls for Gibson’s “ideas” every time, and does not reflect them at all.

    Gibson did not invent SQRL, he gave it a name. The protocol has been around for years and is protected by several patents ( Gibson keeps telling everyone that “his idea” is free to use for everyone. The problem is that is is NOT his idea, and that the individuals and organizations holding the patents will sue everyone who is using the protocol without paying royalties. This might not be a problem for big companies. However, everyone repeating Gibson’s claims without doing any research on the protocol and its origins sets a lot of open source developers who believe this story up for failure, and potentially a lot of legal trouble also.

    1. Earl said on February 19, 2017 at 9:56 pm

      Lots of people “invent” things–and even get patents for them (because the USPTO isn’t all that “bright”); these people are perfectly happy to sue anyone who comes along later with something that these people see as “Mine!” but, in reality, isn’t theirs at all. The actual *idea* predates the patents and the “invention” having been patented. Happens all the time–which is why all software patents are totally bogus.

  2. Dylan said on February 6, 2014 at 2:18 am

    Lot’s of people are questioning this and I suppose that’s healthy. However I think it’s worth noting that Google and the W3C have approached Steve about this. Believe him or not, those organizations will ultimately determine if the solution is viable. Much like having a PIN when using face-unlock or fingerprints on smart phones, I think it’s safe to say passwords will never go away but may take a backseat to a better authentication solution some day.

  3. Ross Presser said on October 11, 2013 at 1:46 am

    The term is and always has been “script kiddie”, and there is no such thing as a “sudo crypto wannabee” — sudo and cryptography are disjoint concepts. I question your seriousness in trying to apply it to the gentlemen on security-stackexchange.

    1. si said on October 15, 2013 at 3:52 am

      pretty sure sudo in this case is ‘pseudo’

  4. Bill B. said on October 10, 2013 at 7:27 pm

    I’ve read the post at “security-stackexchange” and the naysayers appear to be mostly the script kitties (or is it script kiddie?) and sudo crypto wannabes that are against this. How will they be able to hack into and play around someone’s account? Mr. Gibson has talked to other, ACTUAL professionals in the cryptology field and so far no one has been able to poke a hole in it. But like a lot of new ideas it needs to be developed and field tested first. Let’s be a little patient and see what happens.

  5. Ross Presser said on October 10, 2013 at 6:04 pm

    There are significant problems with the scheme and significant doubts about it being necessary anyway. Read the link that jyo posted.

  6. ps said on October 10, 2013 at 9:31 am

    a demo would be great

    LE: Oh, this is work in progress :)

    “What we’ve seen so far are only the broad outlines of the solution, enough to provide an overview of the system’s operation to interested parties, to perhaps convince skeptics that such a system CAN operate, and to create a foundation and interest in the further detailed pages that follow.”

  7. B. Moore said on October 10, 2013 at 8:44 am

    If you want even more info you can listen to Steve Gibson talk all about it on last weeks Security Now podcast #424. Here’s the video

    1. Bernard du Toit said on January 19, 2016 at 9:28 am

      Please note that the features that sets GRC’s SQRL Login apart from the rest, is the fact that it does not use any 3rd party to store or calculate anything related to the identity setup, or login process.

      Referring to the patent mentioned above (, it also refers to using a “TRUSTED SERVER” in the following context:

      “5. Method according to claim 1, wherein said personal secret is provided by a trusted server, which computes said personal secret using a master secret and said user identifier and said time stamp.” …
      “20: the purpose of the Trusted Server is to manage the creation and distribution of personal secrets to users (to their mobile devices).” … “The trusted server must provide a built-in secure communication channel to all mobile devices” … “On the other hand, this channel does not need to be permanently active, it will only be used in the secret distribution phase (see below).” … ” the purpose of the Secret distribution phase is to compute and distribute all personal secrets to every user mobile device. This phase is run periodically (for instance, once a day). The personal secret that is distributed is computed using the current system date of the Trusted Server and is defined to be valid for a period of time whose length coincides with the period of the secret computation. For instance, if this phase is run once a day, then all personal secrets are valid for one day; if this phase is run once a week, then all personal secrets are valid for one week.”

      The second important factor is that GRC’s SQRL Login uses a unique UserID/Public Key for every site you login. So sites cannot share information and build information up about what sites you visit based on your user ID/public key.

      Lastly the encryption technology suite/bundle that is used to do the crypto security is much more involved than simply using a public and private key, to sign a token and date stamp. And using a QR code to facilitate login is not new and was not claimed to be.

  8. Scott said on October 10, 2013 at 1:09 am

    I do hope this gets taken up and catches on. A perfect auth method for Google Glasses also.

    1. Howard said on October 23, 2016 at 8:53 pm

      SQRL simply uses the private bitcoin keys stored in a digital wallet to
      implement public/private key authentication. It does not use the
      security of the bitcoin blockchain. It’s also too complicated and
      unproven compared to the bitcoin blockchain. ChainLock by ChainTight Security is a better
      solution because it leverages the security of the bitcoin blockchain to
      lock down online accounts.

Leave a Reply

Check the box to consent to your data being stored in line with the guidelines set out in our privacy policy

We love comments and welcome thoughtful and civilized discussion. Rudeness and personal attacks will not be tolerated. Please stay on-topic.
Please note that your comment may not appear immediately after you post it.