SQRL has a number of issues, that imho, make it a good example of quality crypto being put forward in a fairly naive way. In no particular order:
1. Keys are generated from the master key in a deterministic fashion. This means in the worst case scenario, where your master is compromised, rolling your keys is an all-or-nothing activity. You could just be in for a fun evening of racing to change all your account creds before a bad guy can use them. The only advantage this deterministic scheme has over a traditional encrypted keyring is that master key backups can be squeezed in to a QR code. The big downside is, if you want two or more accounts on, say, Hacker News you'll need to generate two 'master' keys and maintain a keyring anyway. Ugh.
2. Your super-sensitive master key is stored on all your devices. Sure, it's encrypted... but that means you'll need to enter a secure (realistically a ~8 random alphanumeric character) password, and wait a few seconds for strong key derivation, to use it. On mobile this is just a sucky UX, and will likely encourage users to use weak passwords or app writers to provide weaker encryption options, if only for the derived (site-specific) keys.
3. It doesn't provide server authentication, so you still need to depend on something like TLS + traditional CAs to ensure you're actually receiving your QR code from, and sending your signed response to, the services you expect and not MyEvilSite.com.
4. It doesn't provide integrity between the user agent and the signing device. When using optical scanning there's no way for the app to know that I'm signing facebook.com but my browser window actually says failbook.com. Even if the user is diligent there's no way for the user or the app to know whether the QR code on their screen is actually tied to their session cookie for facebook.com, and not another perfectly valid facebook session cookie created by somebody else. There's a weak proposal from Gibson to include IP binding but the IP isn't user/app visible (and if it were, requiring the user to be aware of such things is just bad UX). And even if IP binding is effective it still leaves you open when the attacker can use your IP (NAT, ARP spoofing etc, XSRF will even bypass TLS). The class of attacks open because of this gap in the auth-chain is one of the most insidious on the web atm.
5. The server side implementation has a lot of moving parts. A typical webapp needs to generate a secure session cookie, optionally bind it to the users IP and generate a QR code, wait for a sig from the signing device (under some timeout as to not allow unused codes to clog up the database), map that sig back to the users session, do IP and signature checking, update the session state and then somehow refresh/redirect the original client (or have them do it manually which is a sucky UX).
Frankly SQRL 'the protocol' just isn't very novel, and Gibson has only scratched at accommodating some of the hard user facing problems. Much of the above can fixed, but not all.
If you like QR code mobile authentication (well actually bar codes), go with Clef. They're still vulnerable to much of the above, only encrypt your 2048 bit RSA master key on your phone using your 4 digit numeric PIN, and it's just vanilla OAuth behind the scenes, but they've at least nailed down usability and settled on a relatively secure compromise.
These are great points, but allow me to add to them:
2. This is similar to what I do with my ssh keys today. I mean yeah the wait time is a bit eh and you are right that people will likely end up degrading their security in order to mitigate it, but what's the alternative? Perhaps better education is in order.
3 & 4. Aren't these solved by requiring ssl, which should be in place anyway for user-based interactions? Also, would you clarify what you mean by xsrf bypassing tls, as I don't understand how that would happen and it certainly sounds quite troubling.
5. This isn't really much more involved than secure user/pass auth, and less complex than oauth for example.
> 3 & 4. Aren't these solved by requiring ssl, which should be in place anyway for user-based interactions?
Not really. There's no way for the app to know whether the particular QR code it just scanned came via a browser session protected by TLS, using a particular CA chain, connected from a particular IP, at a particular time, or with a particular session id. Even if all that information were encoded in to the QR dataset by the server, and digitally signed, it still need to be verified and counter-signed by the browser before being displayed for scanning. All you're really doing is QR encoding a certificate chain at that point... but in order to do that your browser needs to be cryptographically paired with the app.
What you have right now is TLS CA-certified confidence going in to the browser and "the user thinks this QR code is cool" level confidence going in to the app. The user is a poor substitute for a certificate chain.
> Also, would you clarify what you mean by xsrf bypassing tls
Sorry. I meant XSS. If you can inject script in to a TLS protected SQRL page it's game over (you just replace the QR code with one from http://192.168.1.5/MrEvilProxyOnTheSameLAN/dynamically_gener...) then the IP enforcement, as currently proposed, will pass assuming everyone on that LAN has the same external IP. IP bonding is just a lousy way to emulate a decent session layer.... which is ultimately what HTTP needs to nail this down once and for all.
1. Keys are generated from the master key in a deterministic fashion. This means in the worst case scenario, where your master is compromised, rolling your keys is an all-or-nothing activity. You could just be in for a fun evening of racing to change all your account creds before a bad guy can use them. The only advantage this deterministic scheme has over a traditional encrypted keyring is that master key backups can be squeezed in to a QR code. The big downside is, if you want two or more accounts on, say, Hacker News you'll need to generate two 'master' keys and maintain a keyring anyway. Ugh.
2. Your super-sensitive master key is stored on all your devices. Sure, it's encrypted... but that means you'll need to enter a secure (realistically a ~8 random alphanumeric character) password, and wait a few seconds for strong key derivation, to use it. On mobile this is just a sucky UX, and will likely encourage users to use weak passwords or app writers to provide weaker encryption options, if only for the derived (site-specific) keys.
3. It doesn't provide server authentication, so you still need to depend on something like TLS + traditional CAs to ensure you're actually receiving your QR code from, and sending your signed response to, the services you expect and not MyEvilSite.com.
4. It doesn't provide integrity between the user agent and the signing device. When using optical scanning there's no way for the app to know that I'm signing facebook.com but my browser window actually says failbook.com. Even if the user is diligent there's no way for the user or the app to know whether the QR code on their screen is actually tied to their session cookie for facebook.com, and not another perfectly valid facebook session cookie created by somebody else. There's a weak proposal from Gibson to include IP binding but the IP isn't user/app visible (and if it were, requiring the user to be aware of such things is just bad UX). And even if IP binding is effective it still leaves you open when the attacker can use your IP (NAT, ARP spoofing etc, XSRF will even bypass TLS). The class of attacks open because of this gap in the auth-chain is one of the most insidious on the web atm.
5. The server side implementation has a lot of moving parts. A typical webapp needs to generate a secure session cookie, optionally bind it to the users IP and generate a QR code, wait for a sig from the signing device (under some timeout as to not allow unused codes to clog up the database), map that sig back to the users session, do IP and signature checking, update the session state and then somehow refresh/redirect the original client (or have them do it manually which is a sucky UX).
Frankly SQRL 'the protocol' just isn't very novel, and Gibson has only scratched at accommodating some of the hard user facing problems. Much of the above can fixed, but not all.
If you like QR code mobile authentication (well actually bar codes), go with Clef. They're still vulnerable to much of the above, only encrypt your 2048 bit RSA master key on your phone using your 4 digit numeric PIN, and it's just vanilla OAuth behind the scenes, but they've at least nailed down usability and settled on a relatively secure compromise.