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).
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.
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).
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.