SQRL in the wild - well, not really, but pretty close
-
Steve Gibson came up with a new authentication method he calls SQRL (Secure Quick Reliable Login).
The basics are that you'll have an app on your phone/tablet/computer, etc that has a unique to use 256 bit code that will be used to generate unique public/private certs that a website can use to authenticate you instead of using usernames and passwords.
Furthermore, it can be used on untrusted computers, devices to provide out of band authentication. For example, you sit down at a hotel computer, you go to the desired site, it shows you a QR code, you scan it with your phone, which uses it's SQRL client to authenticate you, and the PC webpage refreshes and you're logged in.
So there's the history - I've seen this, sorta, in the wild now. Logmein.com is using something close. Though instead of using a unique sorted 256 bit code, you scan the QR from your phone (which you trust completely, right?) Then you login from your phone with your username and password, after which the webpage on the PC is now logged in, perhaps asking for whatever second factor authentication you might have, or going directly to your computer list.
Pretty cool.
-
That doesn't seem secure. You have to have your phone visible and public (who can hide their phones?) You need to carry the password around with you (the QR code.) So getting "hacked" is trivial both because the phone is the easiest thing to hack of all (typically nothing but a four digit passcode) and getting the QR code is as simple as snatching it (you will always keep it with your phone, I assume) or taking a picture of it. QR Codes are trivial to reconstruct from an image.
Seems like a horrible security procedure to me.
-
The QR code is presented on the vendor webpage each time you log in, you don't carry anything QR related with you. A new and different QR code is generated each time you visit the website with a combination of a nonce and a time code.
As for the 256 bit identifier - it's locked up in app that while not impossible to get the data out of, supposedly not easy either.Of course the 4 digit pin on most people's phone is the weak link, so the app itself has a separate password, hopefully a good one, that can be short circuited for some length of time by a 4+ digit pin (again hopefully different than the phone unlock pin) that after you enter the pin wrong 3-5 times will require the full password to unlock the app.
-
That's better BUT it only works when you have a good screen and the screen is not on your phone. If you implement this for all of your sites, you can't use your phone anymore.
-
why couldn't I use my phone anymore?
Another part of the spec would be a new scheme. Instead of HTTP it would be SQRL. So if you are on your phone (again a trusted device) you would click on the QR code which would provide a SQRL to your phone, it would launch the app, provide authentication and return you to the browser with a logged in session.
As for the screen, I suppose it's possible that you could find yourself on a bad screen, but I can't say that I've used one in recent years that I wouldn't be able to scan a QR code from.
-
@Dashrender said:
why couldn't I use my phone anymore?
How can I get to a site on my phone if I have to use the phone to scan its own screen?
-
@Dashrender said:
Another part of the spec would be a new scheme. Instead of HTTP it would be SQRL.
That's a total fail. Replacing HTTP? That makes very little sense.
-
@scottalanmiller said:
@Dashrender said:
why couldn't I use my phone anymore?
How can I get to a site on my phone if I have to use the phone to scan its own screen?
Because you touch/click the QR when on a touch screen device.
The same goes when you're on your home computer. You wouldn't want to have to pull out your cell phone at home to use your home computer. You'd click on the QR code which would activate the client (much like activating Java), it would do it's part and suddenly your page would be logged in.
-
@scottalanmiller said:
@Dashrender said:
Another part of the spec would be a new scheme. Instead of HTTP it would be SQRL.
That's a total fail. Replacing HTTP? That makes very little sense.
It's not replacing HTTP, it's in addition too. It's how the computer knows it needs to use an additional program that's installed on the device, similar to how the system knows it needs to invoke Flash, or Java, or when you click on a Word document in a page, the system downloads it and auto launches it in word, it's simply another registered extension (scheme).
I did mistakenly use the word 'instead' when I should have said in addition....
-
Oh okay, I see.
-
@Dashrender said:
Because you touch/click the QR when on a touch screen device.
The same goes when you're on your home computer. You wouldn't want to have to pull out your cell phone at home to use your home computer. You'd click on the QR code which would activate the client (much like activating Java), it would do it's part and suddenly your page would be logged in.
What stops something from automating the mouse clicks to automate breaking in?
-
I guess it adds the second level of security because it requires access to your desktop. So it protects the website from being hacked directly but does nothing to protect if your desktop is compromised? How is that better than a key or cookie?
-
@scottalanmiller said:
I guess it adds the second level of security because it requires access to your desktop. So it protects the website from being hacked directly but does nothing to protect if your desktop is compromised? How is that better than a key or cookie?
If you're compromised, all bets are already off. If you think the desktop is compromised, why are you still using it? But if for some reason you don't have a choice, you can fall back to using the out of band authentication through scanning the QR via your phone.
The SQRL client will require you to log into it daily'ish. You'll be able to set the timeout. Also, at least on the phone, the desire is to require the pin if not the password every time you use it, no reason not to do the same on the desktop. This would prevent automated clicking or random friends from just sitting at your computer and being logged into, say, your Amazon account and playing a prank, etc. Of course it would also require that Amazon and the rest play ball and get rid of auto logging in cookies to give their customers more security.
-
@Dashrender said:
If you're compromised, all bets are already off. If you think the desktop is compromised, why are you still using it? But if for some reason you don't have a choice, you can fall back to using the out of band authentication through scanning the QR via your phone.
If it is compromised it isn't you still using it. That's the concern.
-
If your desktop is compromised now, and you're using a cookie or key today they can automate the clicking and do what they like.
If they don't have your pin/password for the SQRL vault they won't be able to log into those sites from your compromised machine, so you'd be a little safer. But it's every bit as likely you wouldn't be aware that you've been compromised and they'd pull your pin/password from a keylogger.
In the end you wouldn't be any worse off than you are today, but you'd be better off for access on untrusted machines, as well as having the ability to have all websites have a unique authentication token (the private/public key pair). Of course it's likely that websites would still want your email address for any number of reasons, but it wouldn't be needed for authentication.
Of course, in your case Scott, at work, where you're not allowed to use your cell phone, or install third party tools, you wouldn't be able to use those services while at work.
-
@Dashrender said:
Of course, in your case Scott, at work, where you're not allowed to use your cell phone, or install third party tools, you wouldn't be able to use those services while at work.
Yeah, requiring some of that stuff is a killer for people in big business jobs.
-
Think of it like LastPass; all your login credentials are stored in LastPass, and LastPass is what fills in the username/password box for you. However it won't fill out your username/password until you've authenticated yourself it LastPass. You can configure your LastPass session to require re-authentication every time, or every 5 minutes, or every hour, or every day, or whatever you want. So depending on how "secure" you feel your system is, you can choose set the timeout appropriately.
EDIT: I'm referring to the SQRL client stuff; not sure about this LogMeIn thing. Seems kind of sketchy to me; very sparse on details. But the SQRL stuff from Steve Gibson I would trust (which is NOT what this LogMeIn thing is)
-
LogMeIn is doing many of the same parts as SQRL, except instead of your mobile device having a unique to you code in it, you have to manually enter your username and password on their webpage from your device.
From what we can see, it looks like an adaptation of SQRL meant to use traditional passwords. I'm not sure how useful it really is - do you store your LogMeIn username and password in the phone's browser? I don't.
But, if you're forced to use a non trusted computer to log into LogMeIn for some reason, this takes away the risk of losing your LogMeIn credentials, but you still have to log into the machines inside LogMeIn. So if there is a keylogger on the untrusted machine, they have captured your computer logons... not really a smart thing to do when you think about it all the way to the end.
-
But are they using SQRL or just their own thing with a similar concept? Seems like it's their own thing with their own app?
The whole concept with SQRL is that there is no username/password. All the site knows about you is your public key, which is what's being authenticated. The site can then link that public key to an account, profile, username for posting on forums, etc.
-
They are definitely not using SQRL. They are only using a QR code with an embedded nonce to do side channel authentication.
But it's a first step. It will take very little effort for LMI to use full out SQRL. Actually I'm not sure what they are waiting for?
