SQRL in the wild - well, not really, but pretty close
-
@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?
