SQRL Secure QR login quick analysis

Post date: Oct 3, 2013 5:01:10 PM

Here's my (really) quick analysis about SQRL.

I did read all documentation available at this point, and here's my comments about it. First of all, there's nothing new with SQRL, it's just utilizing and combining a few old existing tricks.

+ / - analysis and a few questions:

- "But no two visitors will ever have the same ID". - How is that confirmed, generating random 512 bit keys do not guarantee never having same ID. It's just quite unlikely.

- SQRL lacks strong web-site identification, that's a bad thing. Domain name isn't strong authentication. I would like to include strong site identity with within the QR-key. Like the nonce should be signed by site. (Evil website attack, NS spoofing / MITM)

+ No shared secrets is a real bonus. Except, if the attacker has full access to the site already and steals password, they can steal everything else. Therefore if password hashes are stolen, it's major breach of security, and all passwords should be immediately reset. Of course nobody's using same password for separate sites. So, site was breached and thats it anyway.

/ Out-of-band authentication, well, in some cases yes, in some cases no. I wouldn't call this true out of band solution. Especially when using mobile browser, or shared WLAN connection. Fact that authentication data is also routed on same Internet route at the server end sounds quite likely. Of course this can be fixed by service provider if they really want to do it.

+ No third-party, that's the only way to go. In any case when there's a third-party, the solution already sucks badly. That's one of the main reasons why I hate most of SSO solutions. (Single Sign On)

- Mobile (nor desktop) devices aren't secure, having keys in mobile device isn't considered to be secure and those can be extracted. Default mobile device protection isn't good enough for password / identity protection. Most of people aren't even using simple 4 digit pin. Real + would come form completely separate authentication device.

- Using long password with mobile is horrible. My GPG private key password is 20+ chars including tons of special chars. Try typing that with mobile, repeatedly. If shorter pass phrases / keys are used, not enough entropy is included.

- "A password lockout system". Eh? Same method should prevent any web-site password hacks too. ;) Anyway, with proper password, guessing should still be futile, read my statement about password earlier. If the password got even 128+ bits of entropy, it's going to be long guessing marathon. I don't really care even if you try to guess 1 or 10000 pwd/seconds.

/ "such as a personal safe deposit box" - Is not truly secure, what a joke stament.

- Document doesn't describe how identity authentication is linked to the actual client logging in. Basically this would mean that there has to be cookie version of cryptoraphic challenge, or some other data linked to that, which has to be stored for a while at web-servers end. Could this be used to create resource consumption DDoS attack on the service? That's one of the reasons why I don't like solutions which require web-server to maintain state for non-logged in users.

/ What about multiple services on same domain, with different credentials? This is of course quite rare situation nowadays.

/ For computer users there could be the data which is encoded AS QRcode, in plain hex format where you can copy paste the key to the application for authentication. But at this exact point we completely lose the multifactor aspect, but it wasn't strong even earlier.

/ What about replay attacks? Ok, because the site side isn't described yet, and it requires tracking nonces, it's logical that they maintain only recent nonces and remove used nonces from list.

/ I don't personally especially like QRcodes, but that's one way to communicate data to cellphone. Even many mobile payment systems use per terminal qrcodes for payment transactions and "terminal identification".

Additional information, both these are newer than my original post. So the probably contain a lot of new fresh views and therefore are recommended reading if you're interested about this topic.

Hacker News discussion about SQRL

The problem with SQRL

keywords: secure qrcode login, password, passwords are dead, password less, no shared secret, pki, public key, pki.