I just came across https://www.grc.com/sqrl/sqrl.htm

With Secure QR Login, your phone snaps the QR code displayed on a website's login page . . . . and YOU are securely logged in.

This seems like it would be pretty awesome - one of the problems that I can think of is if the QR reader is compromised, to display www.google.com instead of www.nsa-super-secret-place.gov/123. What other problems does this system have?

  • 1
    I don't have the rep to post an answer here, so as comment: As ajedi32 says most answers are severely outdated. Regarding phishing the sqrl protocol could be much safer than passwords as browsers could flag sqrl login codes not belonging to the site you are on as a problem, without knowing your sqrl identity or anything. With passwords that is impossible as there is no standardized way for the browser to know for which site a password you enter is meant.
    – JanKanis
    Commented Mar 4, 2016 at 16:54
  • 2
    FYI, this idea has surfaced again: authentiq
    – NH.
    Commented Sep 17, 2018 at 20:06

7 Answers 7


As usual, take anything related to Steve Gibson with a truckload of salt. Obligatory attrition.org link.

Let's have a look at Gibson's description of his protocol.

Gibon's rubbish

  • The QR code presented near the login prompt contains the URL of the authentication service for the site. The URL includes a securely generated long random number so that every presentation of the login page displays a different QR code. (In crypto circles this long random number is known as a “nonce.”)

  • The smartphone's SQRL authentication app cryptographically hashes the domain name of the site keyed by the user's master key to produce a site-specific public key pair.

  • The app cryptographically signs the entire URL contained in the QR code using the site-specific private key. Since the URL includes a secure long random number (the nonce), the signature is unique for that site and QR code.

  • The app issues a secure HTTPS POST query to the QR code's URL, which is the authentication service for the site. The POST provides the site-specific public key and the matching cryptographic signature of the QR code's URL.

  • The authenticating web site receives and acknowledges the POST query by returning a standard HTTP “200 OK” with no other content. The SQRL app acknowledges the successful submission of the user-signed QR code.

  • The authenticating site has the URL containing the nonce which came back from the login page via the user's smartphone. It also has a cryptographic signature of that URL, and the user's site-specific public key. It uses the public key to verify that the signature is valid for the URL. This confirms that the user who produced the signature used the private key corresponding to the public key. After verifying the signature, the authenticating site recognizes the now-authenticated user by their site-specific public key.

The biggest thing that jumps out at me is the use of a "master key" by the user. If I am reading the protocol correctly, that single master key controls the user's entire online identity...

Presumably, this master key is stored in the user's phone in an application database. Which opens up a huge gaping attack vector in the form of malware designed specifically to steal the master key.

So let's compare the difference between what happens when a password gets compromised vs what happens when the master key gets compromised. Assuming that you are following good password practices of long, unique and highly random passwords stored in a password manager, all you have to do is change a single password if it gets compromised. What happens if your master key gets compromised? You will have to somehow get all the sites you authenticated with to recognize that your master key has been compromised. The only problem is, since you do not have any other means to authenticate with the site such as usernames or email addresses, how will the site know that it is in fact you that is trying to revoke the master key?

Like anything that comes out of Gibson, this SRQL scheme is highly flawed and offers no benefits over conventional methods.

  • 25
    "If you're following good password practices" is a huge caveat, and most Netizens don't do it. Part of SQRL's promise is to reduce users' need to stay on top of best practices. Further, the SQRL spec will call for the master key to be stored encrypted with a master password and will be impossible to brute force (tuned to take ~60s for one try). Getting the password will often be non-trivial since SQRL promotes out-of-band authentication (ie, keylogging a hacked machine won't always help you). So while the consequences of full compromise are high, the likelihood of compromise is somewhat low.
    – spiffytech
    Commented Oct 10, 2013 at 17:43
  • 32
    SQRL may yet have flaws that need addressing, but it claims to solve a number of problems found in existing approaches to authentication, and any criticism of SQRL that asserts it "offers no benefits" should include rebuttals of these claims instead of expecting the assertion to be blindly accepted.
    – spiffytech
    Commented Oct 10, 2013 at 17:44
  • 28
    > Like anything that comes out of Gibson, this SRQL scheme is highly flawed and offers no benefits over conventional methods. --- This doesn't seem to help answering the question, and I actually feel that you have problems with the technology because of who came up with it. Some of the points you mentioned as flaws are actually addressed by the "spec". For instance, SQRL itself doesn't mentions how the master key is stored, but Steve Gibson's comments about it are that a mobile client, for instance, would encrypt it with a master password using a scrypt that takes 60s on average to execute. Commented Oct 11, 2013 at 9:19
  • 14
    Gibson explicity addresses the protection of the master key.
    – MCW
    Commented Oct 11, 2013 at 10:42
  • 15
    Hold on a second. You equate your SQRL master key being stolen to one of your LastPass keys being stolen. Wouldn't it be a better analogy to equate it to your entire, decrypted LastPass password database being stolen?
    – Ajedi32
    Commented Dec 22, 2014 at 20:03

Overall, the protocol does not appear to increase security over existing technology. If you are looking for the best way to protect your identity online, this is without question not it. But let's go over the pros and cons:


It's impossible to "share" a password in the narrow sense that a malicious website can't use the authentication provided to one site to log in to another site.

A brute-force attack against the authentication token is not feasible.

Credentials are not stored on your computer. This protects you against a small subset of workstation-directed attacks. Specifically, you're protected against attacks that steal your password from your computer. You are not protected against any sort of session hijacking or browser-takeover attacks, though, and you are now also susceptible to phone-related attacks. More on that later.


This technique is dangerously susceptible to MITM attacks and social engineering. Probably more so than any other authentication scheme in use, including passwords. The authentication step and the login initiation step are inherently disconnected in the sense that the phone will correctly authenticate against any presented QR code, no matter how or where it gets presented to the user.

So, for example, a phishing site can display an authentic login QR code which logs in the attacker instead of the user. Gibson is confident that users will see the name of the bank or store or site on the phone app during authentication and will therefore exercise sufficient vigilance to thwart attacks. History suggests this unlikely, and the more reasonable expectation is that seeing the correct name on the app will falsely reassure the user into thinking that the site is legitimate because it was able to trigger the familiar login request on the phone. The caution already beaten in to the heads of users regarding password security does not necessarily translate to new authentication techniques like this one, which is what makes this app likely inherently less resistant to social engineering.

This technique combines both authentication and identity into a physical object which is frequently lost or stolen. In this sense it's more like a passport rather than a password. Anyone in possession of your phone is suddenly exclusively in possession of your identity: not only can the attacker impersonate you, but without a second copy on a second phone (unlikely), now you have lost the ability to identify yourself. Authentication keys are not revokable, so without out-of-band recovery from each and every site, you cannot recover your identity. And even if out-of-band recovery exists, when confronted with two users, one with possession of the identity and one without, it may be difficult to see why the site operator should trust you.

This technique combines all your authentication tokens into a single key unless you manually create others. This makes your one key an extra-juicy target for attackers. Furthermore, the key is stored on your phone, which devices have typically had laughably porous internal security. Combining unusually juicy targets with substandard security does not make you safe.


The most problematic aspect of this scheme is how poorly it compares to the available alternatives.

The most secure universally-accepted option today is lastpass, keepass, and other such browser-integrated password systems. In particular, client-side encryption alleviates the need to trust any third party. And more importantly, browser integration makes phishing practically impossible. LastPass or KeePass will only fill the password if served from the correct domain, which means that if presented with a malicious site, the user won't have access to his password.

Furthermore, LastPass recently added a feature which nags users to change passwords that are not globally unique. This helps prevent password re-use, which means the primary benefit of Gibson's technique can easily be gained using this tool today on existing sites, without the added insecurity his scheme implies.

Existing second-factor authentication schemes which use phones or similar devices help protect user logins today already do so in such a way that doesn't make you immediately vulnerable to identity theft if your device is stolen. The added security of two-factor authentication lies in the fact that neither the device nor the password can be used if stolen without the other. Gibson's technique is largely resistant to being included in a two-factor scheme, which makes this level of protection unavailable.


Gibson's authentication technique does not create sufficient benefit to overcome the additional security costs that it also imposes. These costs are a fundamental part of the scheme itself and cannot likely be worked out without scrapping the whole design.

You could argue that it's better than nothing, but you can't argue that it's better than anything we already have.

Gibson's Updates

Gibson recently announced some additional protection against phishing because this has been a major criticism. Their protection is this: If you're NOT using the QR codes, cell phone, etc., and instead have an authentication agent on your system (in-browser, for example), then the server can check to make sure that the authentication response comes from the same IP as the authentication request. This is good and well, but the whole purpose of this protocol is move your identity to your cell phone. If the only safe way to use the protocol is to not use it's core feature, then perhaps we should re-think what we're trying to accomplish.

Theoretically you could continue to use your cell phone if (and only if) your cell phone knew that it was using the same IP as your computer. Which, of course, it can't know because it doesn't know your computer's IP address.

A Better Solution

As stated before, if the authentication measure is in your browser, then the whole phishing problem is immediately solved with no effort or verification on the part of the user. Even the least capable user can't be tricked into authenticating to the wrong site because the site's authentication token is associated with the domain name, and the browser won't allow authentication to the wrong domain. This is a technique already in use today, is completely automatic, and does not require the site's cooperation or any intelligence on the part of the user.

This method can be strengthened by requiring a second authentication factor (such as a time-varying key on a cell phone) which, again, is already available and in use today, which protects you (most notably) against screw-ups on the part of the destination site or company.

As for concerns about browser-side authentication being vulnerable to client-workstation attacks: while the is true, it's also true that if your browser is compromised, then no usage of that browser is safe, no matter what authentication mechanism you use. Malware authors can (and already do) wait for you to authenticate on your own using your super-secure technique, and then silently send the necessary traffic to "own" your account, all without you seeing anything amiss. Neither SQRL nor any other authentication system can protect the user of a compromised browser, any more than door locks can protect you from a house fire. Buying fireproof locks is not a solution.

Where Next

If you're looking for an absolute guarantee of protection from impersonation, then look at the Fido U2F token. This standard shines where SQRL falls short, and gives you guaranteed immunity to MITM (e.g. phishing) attacks. It does so by authenticating not just the user, but also the channel, so you're guaranteed that (a) your account can't be authenticated without the token, and also (b) your token can only be used to authenticate a connection to the machine it's attached to. See this answer for more information.

  • 8
    And about the third point: the same happens with most users that don't use a password manager, by simply using a single username/password in several websites. Or, with users of password managers, whose "identity" is spread on several websites, but stored in one single location (LastPass' servers, 1Password database, and so on). So, it's not really a SQRL flaw. All in all, the more I read about SQRL, the more I see the benefits of it comparing to the current alternatives. Say that you say about Steve Gibson, but SQRL really seems like a good alternative to me. Commented Oct 11, 2013 at 9:33
  • 4
    "The caution already beaten in to the heads of users regarding password security does not necessarily translate to new authentication techniques like this one. . ." This is an excellent point, and the battle has already been lost to marketing. QR codes are seen as an easy way to get things done, not as a potential attack vector. Username/password pairs at least were FIRST used as an authentication mechanism, not a marketing tool. Commented Oct 11, 2013 at 13:51
  • 2
    @jpkrohling: With regard to password managers, I would guess that most users of such software do NOT store their master password on their mobile device, precisely because they are aware of how dangerous that is. I have one physical copy of my master password in a secure location, but no electronic copies. The attacks that would grant access to my master password are different from those that would compromise a site password, and are far less likely. (Primarily because attacking my password database would involve attacking me personally, rather than a large compromised site.) Commented Oct 11, 2013 at 13:59
  • 3
    @jpkrohling Neither LastPass nor KeePass stores a master password anywhere. It's used to unlock your password database, but it isn't stored. This is fundamentally different from having a single key which is, itself, used everywhere.
    – tylerl
    Commented Oct 11, 2013 at 16:55
  • 2
    @jpkrohling WRT redirecting the user to the correct site on authentication: this is fundamentally impossible with SQRL because authentication is out-of-band. You'd instead need a browser plugin or some other client-side agent to handle the redirect, which then defeats the whole purpose of having a QR code.
    – tylerl
    Commented Oct 11, 2013 at 16:57

SQRL certainly is not without flaws, but it's certainly superior to most primary authentication solutions widely used on the web today in terms of security and (and this is important) usability. Allow me to explain.


First, let me clear up a few of the misconceptions present in some of the other answers on this question. Many of these answers are outdated, and were written before changes to the SQRL documentation which address the problems presented in them, while others seem to place undue emphasis on flaws in SQRL which are also present in many other widely-used existing authentication solutions, while ignoring its benefits. So let's clear up a few misconceptions here, shall we?

Myth: SQRL requires scanning QR codes to work

This simply isn't true. QR codes are a convenience which makes SQRL easier to use on computers that the user hasn't set up SQRL client software on. SQRL's website states the following:

Three Ways to Go . . . smartphone optional:

Although the original inspiration for the development of this system was a smartphone scanning a QR code on a website's login page, a small addition to that model enables two more significant modes of operation: Simply make the QR code image also a clickable link to the same URL that's encoded into the QR code. This yields three ways to login:

  • Scan the code with a smartphone: Using the model described above, a user's smartphone scans the QR code appearing on a website's login page and the user is logged into that site.
  • TAP THE CODE on a smartphone: To login to a website ON the smartphone, when the visual SQRL code is also a URL-style link (using sqrl:// as the scheme) the SQRL app installed in the smartphone will receive that link and securely log the user into the site on the phone.
  • Click the code on a desktop or laptop screen: To use the SQRL system on any desktop or laptop system, a desktop SQRL application would be installed and would register itself to receive sqrl:// links. (This is similar to the way an email program registers to receive mailto: links.) This allows the same solution to be used by users on their desktop that they are using on their smartphones. When any website offers an SQRL code the user just clicks on the code with their mouse cursor and the locally installed SQRL app will pop-up, prompt for their SQRL password, confirm the domain, and then log them in.

Myth: The SQRL master key is stored completely unencrypted and unprotected on your phone

I'm not sure why some people made this assumption, as it seems obvious to me that this would not be the case. The SQRL master key is protected about the same way you'd protect a password database: with a strong master password. Stealing a user's phone would not automatically give you access to their online identity unless you also had their master password. More details on key management are explained in the page on SQRL Client-Side Key Management on SQRL's website.

Myth: If your master key is stolen, you can't change your login credentials

This is also false. SQRL provides a built-in way to allow the genuine account holder to update their login credentials in the case of a compromised key. This feature is known as Identity Lock:

“Identity Lock” prevents identity change & allows recovery: This is also significant enough to deserve its own detailed description page: “The identity lock protocol” (page 4 in the link block at the bottom of this page.) Once a user's identity has been established with a web server, the SQRL client is unable to change that identity. This means that if the worst happened, and a very weak and easily guessed password was used, or a user's phone or desktop was hacked to obtain their identity master key and password, no malicious third party can change the user's online identity to lock them out of their own online accounts. And, moreover, by then loading an a normally offline “Identity Unlock Key”, the true owner of their identity can retire and replace their lost or stolen online identity to essentially take it back from any attacker, rendering their previous identity useless.

Plausible: SQRL is more vulnerable to phishing than existing authentication solutions

Okay, so this is actually partially true. When using SQRL by scanning a QR code, there is indeed very little protection against phishing. Unless the user is careful to ensure that the website shown in their browser's URL bar is the same as the one displayed by the SQRL Client app, they could be authorizing a login session for the attacker. This is still better than passwords, where they'd be giving the phisher permanent access to their account (and any other accounts they have elsewhere which share the same password) until they change their password, but not as good as other solutions which integrate with the user's browser like U2F keys, WebAuthn, client certificates, and (under certain conditions) password managers.

However, when you're using an SQRL client on the same device that you're logging in with, SQRL does have some protections against phishing in place. These protections are explained on SQRL's website, under the section on How SQRL Can Thwart Phishing Attacks. There's also the possibility of integrating SQRL with browsers (possibly through plugins) to provide much stronger protection against phishing attacks; on-par with solutions like WebAuthn and client certificates.

Overall I'd rank SQRL on about the same level as password managers for phishing protection. It has the potential to provide strong protection against phishing when installed on the same device the user is logging in on, but provides minimal protection when installed on a different device.

Comparison with Alternatives

Now let's compare SQRL with existing widely-used authentication solutions.


SQRL is vastly superior to passwords in many ways. Not only is it more convenient to use once set up, since users don't have to worry about remembering or retyping multiple different passwords for each site, but it also protects against password reuse, weak passwords, keylogging, and, to some extent, phishing.

Disadvantages SQRL has compared to passwords are that it's more difficult to implement for website operators, not as widely-used, requires more time to set up initially, requires some effort to transfer to a new device, and provides a single point of failure for all the user's accounts if the master key is stolen (though this last point is also the case for passwords if a user uses the same password on every site).

Password Managers

In many ways, SQRL is very similar to password managers. They both provide a single, centralized trust anchor which serves as a sort of authentication proxy between users and individual services. There are a couple ways though that SQRL is superior to password managers.

The main advantage I think SQRL has over password managers is that it's easier and more secure to use on untrusted or only partially trusted computers. For example, say a user wants to login to a website using a computer at a public library. With a password manager, he would have to either access the password for that site on his phone and retype it into the computer manually, or download his password manager and password database onto the library computer, unlock the database using his master password, then log in. The first scenario is inconvenient for the user, and exposes the user's plaintext password for that one site to the untrusted computer (and to any malware on the untrusted computer, including keyloggers). The second scenario is even worse, as it's both inconvenient, and exposes the user's entire, decrypted password database and master password to the untrusted computer. With SQRL, the user would only have to scan a QR code on the untrusted computer's screen, which is much more convenient for the user, and only exposes a single login session (with no reusable credentials like a password) to the untrusted computer.

Another advantage SQRL has over password managers is that it's easier to recover from the worst-case scenario: the user's password database / master key being stolen. With a password manager you'd not only have to change your password on every site, you'd also have to worry about the attacker changing your passwords (possibly locking you out of your account). The attacker also has the advantage of possessing a list of all the sites you have an account on, making exploiting the theft of a password database that much easier. With SQRL, having your master key stolen is still a terrible situation to be in, but the attacker has no list of sites you have an account on (having to instead guess), and cannot change your password to lock you out of your account. Once you load your identity unlock key it's also a bit more convenient to change your login credentials on each site, as the SQRL client has the ability to do it for you automatically for each site you visit upon login. (No need to go through any "change password" forms.)

Finally, I think SQRL has one small but important advantage over password managers in regards to its goal of replacing passwords entirely, and that is that sites have the option of enforcing use of SQRL over traditional passwords. So long as users still have the option of poor security, reusing the same password on every site, that is something that will still happen. If SQRL starts gaining widespread adoption, sites can actually start phasing out the use of passwords. That can't be done with password managers, as they rely on the the use of passwords in order to work.

In terms of disadvantages, I actually can't think of a situation where SQRL would necessarily be worse than password managers in terms of security. The main disadvantage SQRL has is that it requires support from website operators, whereas password managers require no special support from existing services. This means you can start using password managers right now, but SQRL will have to wait until sites implement it before it can be used. This is a significant barrier to adoption.

Client Certificates

The primary advantage SQRL has over client certificates is one of convenience. Client certificates are currently complicated to set up, difficult to transfer between computers, and have privacy issues when the same cert is used on different sites. While theoretically we could build a system using client certificates which would solve these issues, there would also be the problem of poor integration with website UIs and web servers, which are more difficult problems to solve. I won't go into too much detail here, as there's already an excellent article on the usability issues of client certificates on browserauth.net.

In terms of security, client certificates have the disadvantage of requiring the involvement of a CA. This is (potentially) expensive, and requires trusting the third party CA. Furthermore, if you choose to ignore CAs and instead self-sign your certs, you have the issue of certificate revocation to deal with. Client certificates also have the same security and convenience issues as password managers when users want to log in on an untrusted computer; they have to transfer their cert to the untrusted computer, which is both inconvenient and potentially exposes their master identity to malware on that computer.

In short, until someone comes up with a better, user-friendly solution using client certificates which solves (at least most of) these problems, I don't believe client certs are a serious competitor to SQRL (or, for that matter, to passwords).

2-Factor Authentication

Just thought I'd mention this: SQRL and 2-factor authentication are not mutually exclusive. SQRL is a replacement for the first factor in 2FA: passwords. Other additional measures like OTP codes or FIDO U2F keys can still be used with SQRL.


Now here's where things get interesting. WebAuthn is a new (well, newer than SQRL) W3C standard designed to provide a standard API websites can use to authenticate users with public keys on the web. Just like SQRL, it supports using the user's phone to authenticate a login session on an external device, in addition to a few other authentication methods (such as 2nd factor security keys).

This is where SQRL finally meets its match, at least from a security perspective. Not only does WebAuthn provide all the same protections against password reuse, weak passwords and keylogging that SQRL does, but it also provides even stronger protection against phishing by integrating with the user's browser even when authorizing a login session for a PC the user has not previously set up the authenticator's client software on. This is possible because in that situation WebAuthn communicates with the user's browser directly using two-way communications protocols like Blutooth or NFC instead communicating with the website the user is using via a one-way QR code.

From a usability perspective, things are a bit more complicated. On the surface at least, WebAuthn wins again. Because it is a W3C standard which already has implementations in multiple browsers, in theory users can immediately begin to use WebAuthn without needing to install any third party software. In practice though, most existing WebAuthn implementations focus on its use as a form of second factor authentication, or as a way of re-authenticating a user who previously signed in on the same device via a different login method (usually a password). As a primary authentication factor, WebAuthn is still rather lacking in viable implementations.

Other minor considerations include the fact that SQRL has a built-in method for rotating the keys of accounts in the event of a stolen master key, whereas WebAuthn relies on websites to implement their own system for revoking keys, and the fact that WebAuthn requires certain optional hardware (like Bluetooth or NFC) in order to authenticate to a remote machine, whereas SQRL can work on any machine with a working display.

Overall, I think it's very likely that WebAuthn will eventually render SQRL obsolete. SQRL may have a bit of breathing room for now, but WebAuthn has much stronger backing from browser vendors, site operators, and other third party organizations (like the W3C). Once WebAuthn gets a couple implementations enabling its use as a primary authentication factor, I expect it will begin to take over the web very quickly.


SQRL is still under active development, so the material presented in this answer is subject to change. As development continues, I expect that some of the vulnerabilities and uncertainties in this answer will be addressed. Most of the discussion is currently taking place on the SQRL newsgroup over at grc.com.


SQRL is a convenient solution to the problem of the username/password paradox. (i.e. the convenience/security tradeoff) without using a third-party. It provides a simple alternative to the most popular authentication model (Username & Password), with virtually no compromise to security. It is practically just as secure of any of the common authentication models used today, so long as you are still security conscious. If you are using SQRL, it doesn't mean you can't follow best security practices such as combining this with multi-factor authentication for important accounts.

It is important to not the miss the point of SQRL. SQRL itself does not necessary provide better or worse security. If the computer/phone itself gets compromised, or the user is tricked into being phished, then this is a side-channel attack instead of a direct fault of SQRL itself. Every conventional authentication method has this problem of side-channel attacks The unbreakable one-time pad is also vulnerable to side-channel attacks such as the compromise of the pad itself, or bad surrounding security or implementations.

If you listened to the original proposal of the idea on Steve Gibson's podcast, followed by the Q&A's, many of the concerns raised on this stack thread have been answered. Also, Steve said so himself that this very "simple" and "ingenious" (his words) idea would need to be "vetted" and "hammered on" by security experts as only time will tell if this is a secure solution.

In conclusion, most of the arguments against SQRL fall outside the domain of SQRL itself, and instead are problems with humans practicing poor security. SQRL doesn't introduce new classification of problems that our traditional authentication methods already don't have.

SQRL is excellent if used appropriately by people who are security conscious. You must understand that there is always a trade-off between convenience and security, and this solution is probably the best balance of the two I have seen.

  • Thanks Ansichart. But can't existing auth solutions simply retain equal or superior security features to SQRL and then use automation to increase their user convenience? What fundamental property of SQRL's user convenience is not due to automation? I ask because if a user has two black-boxes that do the same thing; one labelled "Mature" and the other labelled "SQRL" and they can be both engineered/automated have the same interface/buttons on the outside of the box - what added-value does SQRL provide? Commented Oct 12, 2013 at 4:06
  • It solves the problem of the password paradox without having to use a third party.
    – ansichart
    Commented Oct 12, 2013 at 4:20
  • 1
    I see. So if someone doesn't want the 3rd-party risk of single-sign-on and won't generate/store their passwords with a password manager, SQRL can step up. But if SQRL is a mobile black-box which asks for a password to unlock the master key used to regenerate/store SQRLIDs and then perform back-channel linking of client's cookie/QR session_id with server's recorded SQRLID to login - how is this a different mobile black-box from a mobile password manager with auto-login via the same back-channel; or a two-party mobile client cert plugin with auto-generation & login via the same back-channel? Commented Oct 12, 2013 at 4:41
  • I have done some major editing of my original post after some second considerations and closer reading to what others have been saying, as I may have over-hyped it. I suppose having the mobile phone being the central key shifts the problem, and would would make it more important to have stronger security on your phone. Steve Gibson also brings this up in the Q&A podcast.
    – ansichart
    Commented Oct 12, 2013 at 5:36

I agree with the other comments to certain degree, but I do think there are some merits:

To enable SQRL for you, you have to create your master key and store it on your phone. DONE. From that second, you will be able to log into ANY website that uses "SQRL". And that would be an anonymous login - as long as you decide to not provide any further information.

That is MUCH easer than working with your own certificate; or creating explicit user accounts (probably asking you to provide a valid email address). Maybe I would not use that same master key for my banking, amazon, ... accounts - but especially for these "i would like to post something here" situations ... perfect. No more "please let google or facebook or whatever site know that you want to post here".

  • 1
    I'm not sure that this is much of a valid point - if you're going to allow anonymous logins then why bother with a login in the first place? A simple captcha would suffice to prevent some spam. Commented Oct 10, 2013 at 14:57
  • 6
    Because the anon login is YOU, just declining to provide any information about your identity; nobody can spoof it. Commented Oct 10, 2013 at 16:02
  • It sounds almost like a half-baked re-hash of Windows CardSpace.
    – Xander
    Commented Oct 10, 2013 at 16:23
  • 1
    Or a captcha, if you are logging in an user which has never logged in before. Commented Oct 11, 2013 at 10:11
  • 1
    "To enable SQRL for you, you have to create your master key and store it on your phone." Actually, you don't need to do that, you just need some software on your PC that can open sqrl:// URLs. Commented Oct 14, 2013 at 21:40

SQRL provides no ground breaking improvements. QR codes are an optical barcode format useful for short content distribution - nothing more.

Any "auto-login" situation that SQRL is trying to solve could simply use a client certificate stored on the mobile instead.

Hypothetically a QR barcode on a HTTPS page could return a server signed or encrypted version of the client certificate (or a similar credential) as previously known by the server, but why? For credential expiration? The site could simply reject an expired credential directly.

So the biggest security problem I have with this protocol is: Reinventing the Square Wheel.


Reading new answers and comments, I'd like to point out how easy it is do something similar to SQRL through simple automation of mature existing technology:

  1. Website asks any CAPTCHAs or similar "I'm a human" verification. Once the user has complied (POSTed), the website returns a HTTP 403.7 - Client Certificate Required or a vanilla 403 error.
  2. Custom 403 pages are easy enough to setup and can be quite pretty and user friendly. Could even bootstrap the functionality required below in a manner similar to the "Adobe Reader required" prompts on many websites.
  3. Custom 403 page includes some markup that a custom browser plugin reacts to. Let us call this custom plugin 'S403L compliant' in the spirit of 'SQRL compliance'.
  4. The S403L plugin generates a standard client certificate, which is secured in the usual encrypted browser cert cache (or a third-party cache if your browser's keystore encryption sucks). The plugin creates a standard CSR for the client cert and sends the CSR to the URL specified in the 403 markup. (e.g. <s403l ref="https://www.example.com/S403L" />)
  5. The S403L compliant server use the user's session_id (retrieved from cookies or query string) to create continuity with Step 1 and then returns the CSR as signed by the server. General server authentication will accept any client certificate that was signed by the server (and thus met the registration criteria demanded in Step 1).
  6. The S403L plugin stores that signed client certificate in the browser's cache. From then on, the standard browser without plugin assistence can "auto-login" into the server in the standard SSL/TLS fashion until the certificate expires.

The "mobile" and "visual" nature of SQRL is something of a misdirection as it doesn't provide detached two-factor authentication and you now need two computers to navigate the internet instead of one. Unless you point your desktop's USB webcam at its own monitor.

The trade-offs between passwords and certificates is well defined in the security community: Passwords fit in a human brain; certificates don't fit in a human brain (usually) but can have crazy entropy and good PKI management features (expiry, revocation, policy extensions, etc). SQRL fits cleanly into neither camp; and if it's drifting towards the less-human more-computer camp as it seems to be - it has years of development and security analysis to repeat existing X.509 features.

  • > could simply use a client certificate stored on the mobile instead. --- except that this technology exists for years both on mobile and desktop, and it's not as widespread as one would wish. And opposed to the client certificate, SQRL doesn't requires you to prove your real identity to create a "SQRL Identity". If you so wish, you can create as many identities as you want. This means that the advantage comparing to Client Certificates is that you have anonymity from the auth protocol's side. Commented Oct 11, 2013 at 9:25
  • @jpkrohling It is a common misconception that client certificates require identity disclosure to use. That is a requirement of commercial signing authorities to use their globally interchangeable trust chains. In practice a client cert can simply be an anonymous CSR created by the client and signed by a specific server, after meeting whatever criteria are desired (CAPTCHAs, prior account, etc). Certificates can also have a built-in expiration. Type 40-L QR barcodes could dispatch/store the 1KB X.509 client cert if desired. Commented Oct 11, 2013 at 10:13
  • Ok, true, my bad. From this perspective, the client (mobile app, for instance), could be generating a client cert for each website that the user is registering. This sounds more expensive than hashing some information, but could be an interesting solution. In any case, I still don't agree with your claims that SQRL is worse than useless. Commented Oct 11, 2013 at 10:25
  • 2
    @LateralFractal who cares if it's new or not? SQRL allows user friendly authentication where the 1st party does not expose their secret with the 2nd party or any 3rd party who might have compromised the 2nd party's security. It's an attempt to solve a real world problem that, so far, nobody else has been able to solve. Commented Oct 16, 2013 at 21:19
  • 1
    @AbhiBeckert And around and around in circles we go. If it is not new, then by definition the problem has been solved before. So I'll reiterate: SQRL is simply an automation and distribution channel that could have been implemented on existing standards. But then the inventor (I use this term loosely) would be contributing a tool or plugin to automate existing technology instead of the publicity benefit of a home-brew solution with their name attached. The vast semi-anonymous contributors who keep your browser and IDE afloat don't crave ego-reinforcement to extent of reinventing the wheel. Commented Oct 17, 2013 at 1:15

I would like to address the first question: "one of the problems that I can think of is if the QR reader is compromised, to display www.google.com instead of www.nsa-super-secret-place.gov/123":

The master key is used as the seed into HMAC together with the website address (FQDN). So although the QR code may encode completely different URL the protocol will NOT reveal the authentication code that would normally be sent to www.google.com (in the example).

Second, many of the contributors forget about the key objectives when working this idea out:

  1. anonymity by not using 3rd party
  2. ease of use
  3. no need to type secret credential on untrusted computers

I believe the protocols addresses these in full!

However, there are compromises that actually come from the the first obectjive. If no 3rd party is involved in the authentication, how can one revoke their authentication details? Additionally, the security of the master key is an obvious concern. I envisage this to be well protected by future mobile devices in a HSM like chip. Until then, the key is just a file pin mobile device, protected by a password, though PBDKF2 ensures that it is very slow to actually brute force it.

  • 1
    Again,what's new about this idea? It seems to me to be a primitive variation on the now defunct Windows CardSpace.
    – Xander
    Commented Oct 10, 2013 at 20:10
  • 1
    Yes you are right about CardSpace. Then there is U-Prove also owned by Microsoft. The question is how would you use CardSpace or U-Prove on a computer that you do not trust (internet cafe or friends computer). That is what Steve added. Commented Oct 10, 2013 at 20:28
  • 2
    Ah, ok, that's what I was missing. I still agree with @TerryChia that this is a non-starter without a revocation mechanism for the user keys.
    – Xander
    Commented Oct 10, 2013 at 21:03
  • 3
    @Xander There is a revocation mechanism for the user keys. grc.com/sqrl/idlock.htm
    – Ajedi32
    Commented Nov 5, 2015 at 15:05

You must log in to answer this question.

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