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 succeptible 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 posesssion 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 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.
Finally, 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 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.