After seeing Steve Gibson’s talk about SQRL today it just occured to me how easy it would be to weaponize SQRL to effectively attain permanency on systems. Below I’ll present a few attack scenarios that can give an idea of some of the vulnerabilities of the system that make me uncomfortable.
Seeing the talk I also have some concerns about the use of structures like EnHash and EnScrypt instead of proven algorithms like PBKDF2 or Argon2 respectively. But I’ll keep these away from the equation as we have still no proof that neither is vulnerable.
As you will notice, most of these scenarios deal with two parts of the protocol, the 24 digit recovery code and the bits that disable the recovery procedures and any login methods other than SQRL.
So let’s start: when you create a SQRL key you are provided with a 24 digit recovery code that you are expected to physically save in order to be able to perform special operations like key recovery or rekeying of the identity.
Additionally, once you feel comfortable enough with SQRL you can ask a site to prevent logins using anything other that SQRL and disable the recovery procedure too.
It’s quite obvious then than an attacker knowing a specific user’s username and password on a SQRL enabled site can just create a new SQRL identity and then register enabling those two bits in order to effectively lock out the user whilst retaining access. A similar attack based only on a password and/or e-mail change would instead likely fail when the user received an e-mail to confirm the change (if the system was properly implemented).
But this is not the only case, of course. With SQRL, your security becomes that of both your database and you 24-digit recovery code.
Let’s suppose an interesting target is using SQRL. We have an idea of where that target is hiding the 24-digit code and we have secured access to the system such target uses for daily SQRL operations. We could then monitor the target’s activity to figure out when he is away from the place where the recovery code is suspected to be, then simultaneously steal the code along with the SQRL database and finally perform a rekeying on the websites we are interested in to prevent the target from accessing them. We could also use the bits to disable recovery a non SQRL logins to complete the attack.
Of course I may not need to complicate things so much. If I have access to the system running SQRL and I can convince the user to rekey I may still be perfectly able to extract the recovery code then along with the database and perform the same attack as before.
Finally, you’ll notice that the system provides you the ability to print out the recovery code and displays it on the screen. This raises a few questions as you can’t be sure for how long your job may remain on graphics memory, on print queues or on printers once it is sent. This entails that an attacker can focus on these systems instead of the physical paper in order to perform attacks. Of course the likelihood of success decreases with time but I do not expect users to be aware that they shouldn’t use a network printer.
Steve also mentioned that, at least on his client, recovery codes can’t be recreated if a compromise is suspected which may make many of these attacks easier. Not that it would matter though as keys encrypted using the old code may remain on the hard drive for a long time.
Does that means I think SQRL is broken and should avoided? Well, yes at least in part. The ability to prevent further logins via other methods and disabling account recovery can be a serious issue, also with SQRL your security will be as good as your physical security is, which for many is basically none. That doesn’t mean though that you shouldn’t use SQRL, as a site administrator it may be interesting if you either ignore the bits to disable further non SQRL logins and account recovery or treat them with the same care you would treat any change that would lock out a user. Similarly you should treat a new SQRL binding in a similar way as an attacker could otherwise use SQRL to grant permanency on the account even if the password is changed. Finally as a user you should be aware of the physical limitations and risks that SQRL can entail, specially if you are a particularly sensitive target.