I just listened to Steve Gibson’s SQRL (Secure QR Login) authentication scheme. I’m not a cryptographer, but I see some minor issues. I’d appreciate people correcting me and educating me. Here are a few issues I have with the authentication scheme. But to be brief, I think there are problems. [Added note: This post was based on the October 16th podcast where Steve first described SQR, and it’s benefits. The transcript is here. Steve has refined and further documented SQRL since then. ]
No email addresses are used
A big advantage of SQRL, according to Steve, is that SQRL doesn’t use email, which is great for the user who wishes to remain confidential. Of course, the IP address and other browser details can be captured, so using SQRL doesn’t provide true anonymity.
However, many sites require an email contact for many reasons:
- They want the marketing capability. And the email allows them to send you promotional material.
- They want to have a way to asynchronously contact their members in case of an emergency.
- They want to prevent automated systems, and spambots, from generating millions of accounts for their site.
Personally, I like the ability to log onto a site without an email. But I’m not paying for the web site. The paying owners have final say. So the first issue is getting the web sites to want to provide this feature. And not all sites will want to offer accounts without email addresses.
[Update – I elaborated on this in a newer post. ]
SCRYPT is recommended on smartphones for “deep encryption”
Steve suggests that the master secret key is stored on your smartphone, and that “deep encryption” is used to encode this secret key when exporting it. He suggests that scrypt be used, and that it takes “60 seconds” on a smartphone to do the encryption.
Scrypt is memory intensive, and many smart phones have limited RAM. Steve says “You could say we want a megabyte.” The problem is that while it might take a memory-limited smartphone 60 seconds to perform th that can perform the same e algorithm, one can get a server with 128GB of RAM that can perform a brute-force attack as a much higher rate.If it’s too memory intensive for a server with huge RAM, a smart phone won’t have the RAM to do the same algorithm in a reasonable amount of time.
It’s not “Out of Band” and has nothing to do with a camera
Steve mis-spoke when he suggested SQRL was “out of band”. The podcast also says it requires a “device with a camera and an Internet connection.” But this is wrong. The camera has nothing to do with it. You can’t use the smart phone to take a picture of itself – unless you use a mirror. You are doing a screen capture/screen grab, and the camera is not, and never was involved. It just confuses the issue.
SQRL:// is a bad idea
Steve suggest that a special URL tag such as SQRL:// might be used. This is not a good idea.
First of all, we know we want to have a HTTPS:// URL to log onto a web site. Anything else provides an opportunity for a man-in-the-middle attack. You don’t want to perform part of an authentication with SQRL:// and a second part with HTTPS://. The two sessions would require the passing of cryptographic state between them, and allowing a moment of interception just provides an opportunity for something bad to happen. It’s better to start with HTTPS:// and use the single session.
There is no reason to use a QR code
The QR code allows you to store the info on a piece of paper, and lets you “import” it back into a computer with a camera. And it provides a easy way to see that the web site offers SQRL login. But realistically, there is no reason that QR codes be used on the web page. As I said – the camera is never used during the authentication process.
Steve’s proposal uses the QR code to provide a string of numbers. The same information can be provided in the HTTP header. This simplifies the process because a GIF does not need to be converted into an ASCII string.
An ASCII string is preferred because (a) this can be provided on a https: page, which can be authenticated, and (b) a browser can automatically log someone onto a web site with a browser plug-in, if they chose to.
SQRL should not rely on a human to authenticate a domain
Hackers can create web sites that look very much like a legitimate site. They can change a “l” into a “1” and some fonts won’t show a difference. An “o” can be changed to an “0” or using accents in domain name. An example is totålly.com vs totally.com.
Or else they can create a host with a domain name that is so long, that it will be truncated, and the truncated name looks legitimate.
The only way this authentication system work is if the authentication process checks the domain name from a whitelist of approved domains – automatically. A human can be fooled.
SQRL cannot detect DNS poisoning
SQRL cannot by itself be used to detect a malicious site using DNS poisoning. A hacker can inject a bogus IP address into a DNS server, and trick a user to loging onto a bogus site. Unless Secure DNS is used, SQRL will not detect interception.
SQRL cannot not detect expired domains
A SQRL code can be years old. SQRL has no way to detect this problem, because there is no way to expire the web site unless some external clock is used. HTTPS/SSL does detect this problem – because expired certificates can be detected, and the client can refuse to connect which this occurs.
Also – someone may forget to renew their domain registration, and someone else can swoop in and set up a replacement domain. SQRL cannot detect this. HTTPS can.
HTTPS can be used for mutual authentication.
I’ve explained why SQRL cannot authenticate a web site. HTTPS addresses these issues, and is superior in all respects – except that it doesn’t provide frictionless authentication. However – it could if the web site owners choose to use this.
HTTPS can use mutual authentication – with client-side certificates. The main reason this isn’t often done is that it’s a hassle to installed a signed certificate into a client, and having multiple web sites agree to the same certificate authority.
But if the web site allows self-signed certificates as part of the authentication process (in stead of a certificate signed by a third party), then HTTPS provides all of the features of SQRL – and none of the problems. And this uses a well-studied protocol.
If a web site owner configures their web site to perform mutual authentication and allow self-signed certificates, then as far as I can tell, this has all of the advantages of SQRL, and none of the disadvantages.
So I don’t see any reason to use SQRL.