New Standard For Website Authentication Proposed: SQRL (Secure QR Login) 234
fsagx writes "Steve Gibson has proposed a new standard method for website authentication. The SQRL system (pronounced 'squirrel') eliminates problems inherent in traditional login techniques. The website's login presents a QR code containing the URL of its authentication service, plus a nonce. The user's smartphone signs the login URL using a private key derived from its master secret and the URL's domain name. The Smartphone sends the matching public key to identify the user, and the signature to authenticate it. It may be used alongside of traditional username/password to ease adoption."
Challenge/response tunneled inside of SSL? (Score:1)
So, basically... challenge/response tunneled inside of SSL, but with a QR code? Quick, get the patent office on the phone.
Re:Challenge/response tunneled inside of SSL? (Score:4, Insightful)
I recently checked out the two podcasts where he went into extensive detail on SQRL and he made it pretty clear that he isn't looking to make money on this concept if it were to take off and that he "doesn't really even have time to do much with it". He presented his idea, documented it, opened up some discussion about it and a forum for people to discuss it in and left it at that. Say what you may about him, but I don't get any sort of "erhmagerd, I'm gonna get rich off this" going on here. I'm sure if clear flaws are demonstrated to him, he'd readily discuss them and admit them when they were uncovered.
Google already dunnit (Score:3)
Re: (Score:3, Interesting)
I am *shocked* by the thought that Steve Gibson would claim something as an innovative and original idea that turns out to be old and tired. Shocked, I tell you! Surely this has never happened before... (http://www.theregister.co.uk/2002/02/25/steve_gibson_invents_broken_syncookies/)
Smartphone required to browse? (Score:3, Insightful)
Re:Smartphone required to browse? (Score:5, Insightful)
Re: (Score:2, Insightful)
But their website says:
It eliminates every problem inherent in traditional login techniques.
So I guess they're just swapping new problems for the traditional ones ;-)
Re: (Score:2)
Re: (Score:2)
so, tying identity uniquely to a device is actually the intent here
Banks and credit unions already do this sort of two-factor auth: "We don't recognize your computer. Click here and we'll send you an e-mail or text message or call you with a code to access your account on this device. You'll only have to do this once for each device."
Re: (Score:2)
*every time you clear your cookies
FTFY
Re: (Score:2)
People still do that? I don't think I've cleared my cookies in five years...
Re:Smartphone required to browse? (Score:5, Insightful)
You must not binge drink.
Re: (Score:2, Interesting)
Pull out your cellphone. Click. Now your IP on the cell and phone are tied to your browser session and it's IP address. If geolocating wasn't easy enough, they have you at a doubley coordinated vector.
This one bites-- why not a Yubikey or another more easily used and less invasive secondary auth? It's not so much the niceness of a secondary auth, rather, it ties too much data for somebody's hadoop mosh pit.
Re: (Score:2)
Not to mention your location. Getting location services is a standard part of HTML5 and is how mobile Google Maps works. So they can get your location, force you to watch some ads before letting you in, etc.
Re: (Score:2)
No, 2 smartphones required to browse. (Score:3)
Actually, two smartphones required to browse. One to navigate to the website, the other to take the picture of the QR code on the first one's screen. Oh, and you'll probably need a third hand to type in the password that is computed on the second phone into the password box displayed on the first phone.
Scanning random QR codes (Score:2)
Also, I go to a website on my smartphone. How do I scan the QR code? With my other smartphone?
Re:Scanning random QR codes (Score:4, Funny)
Are there people who still carry only one 'phone around? And yet people rely on them so much.....
Re: (Score:2)
No. That's where the QR code also being a clickable link comes into play.
This SQRL thing is documented on his site and he has a forum open to critique it and expose flaws in it, so this stuff is all easily accessible to anyone who wants to take a half hour to read it.
Re: (Score:2)
So you go to a website and it displays a QR code it wants you to scan. Who knows where that QR code could redirect too.
Also, I go to a website on my smartphone. How do I scan the QR code? With my other smartphone?
Easy! You snap a photo using your webcam so your computer can authenticate you!
</sarcasm>
Re: (Score:2)
Exactly! That's why the authentication app on your phone (which is currently being developed) will DISPLAY the proposed URL, and ask you to confirm "Is this where you were trying to log into?". It always confounds me how QR codes are everywhere.... On cereal boxes, posters, in movie trailers, etc... and the people who place them there expect users to just blindly take a photo of them and g
That's how I say SQL (Score:2)
Programmers argue whether the right way to say SQL is S Q L or sequel. A business analyst told me her way, and I thought it fit best: squirrel.
Re: (Score:2)
I've honestly never heard anyone debate this. It's called My ESS CUE ELL and PostgrESS CUE ELL, because SQL is pronounced as each letter. Yes, people sometimes mispronounced it, but that is due to ignorance. The same way we all used to know people just coming to the web for the first time who thought that URLs were pronounced like they were part of the monarchy.
Re:That's how I say SQL (Score:5, Funny)
"MySQL" is pronounced "Why aren't you using PostgreSQL?"
And "noSQL" is pronounced "no".
Re: (Score:3)
Re: (Score:2)
It was SEQUEL first (Score:2)
Yes, people sometimes mispronounced it, but that is due to ignorance
Actually, the ignorance is people that aren't aware that it was originally called SEQUEL and then renamed to SQL. There have been various products over the years on various platforms with the SEQUEL name (80's and early 90's). The pronunciation has been both ways, although as time goes on there are many people like yourself that just aren't aware of the history and other pronunciation and so it continues to fade.
Re: (Score:2)
I've always pronounced it Post-Grey-Sequel
Re: (Score:2)
"PNG", but pronounced "pong" because it comes with an air of smug.
Re: (Score:2)
> So is it "gee-eye-eff", "giff" or "jiff"?
Step one: learn Italian.
Step two: now "gif" is pronounced "gif".
This is how it feels to have a sane language.
You may curl up and cry now.
Re: (Score:2)
The vowels in "SCUBA" go a long way to making it acceptable as an individual word. There are no vowels in "SQL". Unlike SQL, SCUBA is not commonly encountered in the areas of Information Technology and Computer Science, in which the use of acronyms is commonplace and well accepted. (Cue the story* of the IBM engineer who had to ask his client what was meant by F.A.N. in a maintenance request. Upon being told that fan was a word, not an acronym, the engineer informed the client that the correct term was in
Re: (Score:2)
Re: (Score:2)
About Mr. Krwzyk - That's about pronunciation of words in another language. What's your point? I knew a Chinese guy whose name could not even be correctly written in English, but there are accepted conventions (dogma, if you will) on how to write, in English, the phonetic representation of such names.
It's been my experience that people in the IT world are very comfortable with the use of abbreviations and acronyms and rarely "wordify" the unpronounceable ones to make them pronounceable (EBCDIC qualifies,
Re: (Score:2)
I worked as a DBA for over a decade and never once met a DBA who pronounced it as anything but "sequel".
MS sequel, My S-Q-L , officially S-Q-L, Chamberlai (Score:3)
The MySQL team says S-Q-L, and I believe their web page says that's how their name is pronounced. The official SQL standard says it's s-q-l.
On the other hand, it seems to me that Windows admins tend to say sequel. The primary author of the language, Chamberlain, says sequel.
Putting all that together, neither is really right or wrong. When talking about Microsoft's rdms to Microsoft-based listeners, sequel will elicit the fewest snickers. In the FOSS community, say My s-q-l. S-Q-L is the standard data m
Re: (Score:2)
There's no 'R' in 'SQL'...wouldn't it make more sense to pronounce it 'squeal'? And I believe there is a Squirrel SQL client out there somewhere.
Re: (Score:2)
My girlfriend calls it Squall.
You're saying that's what she said?
Re: (Score:2)
I was thinking it should be called that... because, as a language, it blows.
I love standards! (Score:2)
There are so many to choose from.
In this case, the proposer seems to be under the impression that a desktop, laptop, or tablet is more likely to be compromised than a smartphone.
SSL client certificate authentication (Score:2)
Isn't this exactly what happens during SSL client certificate authentication? Modulo routing the response through a smartphone, that is.
Re: (Score:2)
Basically, yes, but client certs change. Gibson wants to keep a static cert -- Or effectively: use HMAC( clientID , domain ) to generate a cert, so one client secret is kept safe, and used to generate a different cert for use with each domain, in such a way that you can re-generate the cert for any domain.
The system falls down on two points: It's essentially the same as existing tech: SSH keys, or password protected PGP keys. IE, the single point of failure is the same; And the authentication is cued via i
Re: (Score:2)
Client certificates shouldn't change, at least not until they expire. And for authentication the site should be issuing the certificate so they can control expiration. But yes, there's supposed to be support for all this. I think the primary blame is Internet Explorer: it wouldn't support anything but Basic authentication and Windows-specific methods, and it wouldn't work correctly with any unsupported methods unless Basic was the first method. Meanwhile other browsers followed the spec and used the first (
Soon to be enabled (Score:3)
Wow. (Score:4, Funny)
Google Auth beat you to it (Score:2)
Any better than SSL client certs? (Score:2)
They already exist and are supported, doing pretty much the same thing on a secondary device does little to improve things.
Re: (Score:2)
The point is to allow access to a site from a public computer that may be compromised without needing to enter your credentials on the site.
Re: (Score:2)
The point is to allow access to a site from a public computer that may be compromised without needing to enter your credentials on the site.
What would the point in this exercise be other than inviting yourself to get totally fucked over?
Lets say for example the site in question is a webmail account. Very common. After I have logged on using squirrels from a possessed computer I don't trust with my password (So there!) the computer forwards all of my messages to the New York times, tells all of my contacts I am sexually attracted to squirrels and changes my password all while a I am sitting clueless waiting for the "slow computer" to just show
Re: (Score:3)
Lets think a USB hardware token? The private key never leaves the device that has a dell defined api and is built from the ground up for security. But this does not help (nor would the SQRL bits) the compromised box from hijacking the session.
Re: (Score:2)
Why would you want to let Dell define you're api?
Seriously, though... Call me paranoid, but I think plugging any of my USB devices into the PC equivalent of a Korean War-era B-girl is even *less* desirable to putting my username/password into one.
Re: (Score:2)
Typo well not dell. Your ok with putting you username/pass into something but not connecting a heavily secured computer on a usb stick?
Re: (Score:2)
No, that was my point. If I don't want to put my User/pass into it (if I did, I wouldn't be using this thing anyway), I sure as hell don't want to plug a device into it.
Re: (Score:2)
Yah! I'm authenticated on a public computer that may be compromised! Now the compromised machine can act as me! You're a moron.
Browsing on a computer that's not your own (Score:3)
Re: (Score:2)
An this is better than a USB security device (hell even a phone app and cable)? When you pull out the USB you can no longer many any new connections. SQRL revocation?
Re: (Score:3)
An this is better than a USB security device (hell even a phone app and cable)?
It works even when USB sockets are full of epoxy, as is apparently true of a lot of public computers, or on devices such as the iPad that don't really have a general-purpose USB host.
SQRL revocation?
Apparently the SQRL authenticator app gives each site a different user ID number, and the user can revoke an ID number within the app.
I have a better idea (Score:5, Insightful)
The endless parade of cheap hacks needs to stop. Anything less than strong bindings between session encryption and authentication is short changing everyone.
Get browser vendors to apply the TLS-SRP patches sitting in their ticket systems.
Re: (Score:2)
This methodology requires no patches. No vendor co-operation. Just a little crypto challenge. No more worrying about third parties or passwords. Session encryption is useless if they've already logged your keystrokes, or the ISP gave your keys away or provided their SSL certs to the government. Encryption is necessary, but the problem is passwords, always the passwords.
And it is an expensive hack, thanks you. Lots of time being spent on it.
Re: (Score:2)
SQRL doesn't present a password to any site. It provides an answer to a crypto challenge that can only be answered by the user stored password. No rainbow table is gonna get that. Rainbow tables don't contain all the numbers in the universe.
This Is The Auth Schema I've Been Waiting For! (Score:2)
So you need to have your phone present and with a connection to login?
And it's basically just OAuth with an added device dependency?
FINALLY! As a SADO-MASOCHISTIC Web Developer, I've been pining for an authentication schema that is as equally painful to use as it is to implement that provides no real added benefit over what we currently have!
Ohhh Steve Gibson -- you are a fucking genius!
Re: (Score:2)
Re: (Score:2)
No. Read. Read.
Not foolproof (Score:2)
The Smartphone sends the matching public key to identify the user, and the signature to authenticate it. It may be used alongside of traditional username/password to ease adoption."
Attack method: the attacker presents to the user a fake website, proxying the real QR login image.
The real user, goes through the signature shenanigans, causing the attacker's browser session to be authenticated, when the user types in the password and hits OK.
The attacker leverages a man-in-the-browser attack to
Sounds like client certificates to me... (Score:2)
...but instead of storing the certificate in a moderately secure environment (the browser) it's stored in the least secure environment available to the user, the mobile phone. Not only does it not have any security against remote exploits, securing it physically is also next to impossible.
Re: (Score:2)
No. It is stored, encrypted, on the phone, or the computer, or the tablet, or the USB stick, by the user, who is responsible for its security. what "browser storage" means, I do not know. If the master key is encrypted in the usual fashion, only the user has the password necessary to unlock it, just as in Truecrypt's case. It's gotta be somewhere. This way, it doesn't exist anywhere else in the universe but that device (and anything else you can store it, encrypted, as well), so no certificate hijacker, no
Similar proposal (Score:2)
A few days before I first heard of SQRL (a few weeks ago) I came up with a very similar proposal, which I published on my blog http://ddevnet.net/posts/anonymous-authentication-with-pk.html [ddevnet.net]
SQRL works around the biggest hassle with my proposal which is linking the browser and the certificate to a session. The QR code idea really streamlines the workflow. My proposal could probably adopt this idea. Where our proposals really differ is that I believe that keeping your keystore anonymous is important. With SQR
On my phone (Score:2)
smartphones only webisites, you mean? (Score:2)
So, you can't tell, or can't log in, unless you own a smartphone (tm)? Quite so, mine citizen. Please show me your citizenship documents on your smartphone... you don't have one? Please accompany this fine officer to the station for violating community standards....
mark "fsck smartphones"
Re: (Score:2)
no. as it has been written and said, many, many, many times, you do not need a smartphone.
Re: (Score:3)
Eh, our whole country adopted nonce [theguardian.com] for nearly four decades.
Re:Steve Gibson is a... (Score:5, Informative)
I invite everyone to let Google autocomplete that sentence. It's been well-known for a good while that absolutely no-one should pay any attention to him.
Just for giggles I did test auto complete on that and it gave:
1. steve gibson is a fake
2. steve gibson is a moron
3. steve gibson is a idiot
Could that be considered the -opinion- of the Google algorithm?
My opinion about TFS involves squirrels too. But mainly their primary food source ( pronounced 'nuts').
Re: Steve Gibson is a... (Score:5, Insightful)
Re: (Score:2)
He's 57. Ain't a noob. The attacks were like, ten years ago. They're like a bunch of evil ex-girlfriends on Facebook against whom he really needs a restraining order. No one really cares what the "community" thinks, if what you mean by that is the group that has the time and inclination to launch DDOS attacks and spam threads with "Gibson sucks" posts. I don't believe people of that disposition really matter if they're over 15 years old. Nobody even remembers what the hell he did "wrong", and frankly no one
Re: (Score:3, Interesting)
But, one big problem I see with this, is likely that you will be giving your fucking phone number to every website you want to log onto using this.
I'm trying desperately to not give them any identifiable information on who I am, not more!!
Re: (Score:2)
I guess you didn't read the spec, no identifiable information needs to be sent.
Re: (Score:3, Insightful)
Re: (Score:2)
But, one big problem I see with this, is likely that you will be giving your fucking phone number to every website you want to log onto using this.
Why would you do this? SQRL doesn't require you to give your phone number to anyone.
Re: Steve Gibson is a... (Score:4, Informative)
From TFA:
1. No cell phone required.
2. No QR code required.
3. err, no cell phone required
4. It's stored encrypted by a local password
Re: (Score:2)
I also think that the system is overreliant on a person having a smart phone. I often go places without one and am seriously considering getting a dumb phone for private use (weekends and evenings). This system would not work for me or the millions of other people that do not want or do not have one. If a system relies on a phone, how is this better than current systems that send me a OTP on any mobile using basic SMS. It is more complex but not more reliable as the weak link is regarding who has your p
Re: (Score:2)
Also it doesn't even require QR codes, you just need a link on the page with sqrl:// instead of http:/// [http] to launch the authentication app.
Re: (Score:2)
How exactly is it a "comprehensive analysis" if it ignores dictionary attack strength?
How is it "comprehensive" if it ignores the fact that an attack can be crafted specifically for this technique?
All it discusses is brute force, which is pointless beyond a few characters.
Re: (Score:2)
Oh, seriously, get a life.
Re: (Score:2)
Re: (Score:2)
Ideally, sure.
In a world where the ravages of entropy are bringing you ever closer to the end of your finite lifespan, you just end up pissing away a whole lot of time.
Re: (Score:2)
I'm not sure what you're getting at. What has one got to do with the other?
Re:Gibson is NSA... (Score:4, Informative)
Wasn't Gibson one of the first people we heard a reasonable explanation of the NSA tapping from? When we were all blaming Facebook and Google and Facebook and Google were denying direct feeds to the NSA, he asserted that what was probably happening was tapping of the trunk just externally to the private points of these entities, such that they may never have even known it was going on. Then, it turns out, that is pretty much what was happening in many of the cases.
I don't know a whole lot about the guy, but he sure seems to have an awful lot of anti NSA and pro-privacy stances, as far as I can tell.
Re: (Score:2)
To be fair, there is a wealth of links debunking his claims. That post has a decent amount of evidence to support the assertions.
Re: (Score:3)
One of the main things it's supposed to address is to allow secure login from a public computer. A computer could have a software or hardware key logger, but since the authentication is handled by the phone you control it doesn't matter.
It also has a unique ID that's based on a hash of the site you are authenticating with, so accounts at different sites can't be tied together unless you give the site something like an alias or your email address.
This does raise the problem in that it makes your phone the k
Re:What problem? (Score:5, Insightful)
Unfortunately, that entire concept is flawed for at least two blindingly obvious reasons:
This does not solve the man-in-the-middle attack where untrusted endpoint devices are concerned, because that problem is a fundamentally unsolvable problem. If you cannot trust both endpoints, no secure connection is possible. This is a fundamental tenet of computer security.
In particular, if you can't trust the endpoint, you can't trust anything that the endpoint presents to you. Unless this scheme literally requires you to point your phone at the screen and authenticate every single action, there's nothing stopping someone from tweaking the content on its way to the untrusted screen so that the logout button doesn't actually log you out, but instead merely shows a fake logout screen. Then, the person who owns that untrusted computer has access to your account.
And even if you try to patch around that with a QR code that deauthorizes the computer, there's nothing stopping someone from automatically transferring money to a bank in the Cayman Islands right before it requests that logout code, or whatever. So even in the best case, this does not really add any significant amount of trust to the untrusted device.
Re: (Score:2)
More than that, this is also vulerable to a MitM relay kind of attack, similar to a phishing page that looks like the original login page. This is made worse in that a smartphone can't automatically verify that the computer is on the correct domain before authorizing the page displaying the authentication page.
This results in a similar situation to your 'untrusted terminal' scenario, where the bad guys have a valid login to your account and can do what they want with that session.
Possibly even let you also
Re: (Score:2)
Different, but similar, anecdote: We had a course on the telecoms network infr
Re: (Score:2)
I don't see a comparison of ip addresses stopping a malicious site from pulling a real QR code and presenting it to the user who then authorizes the session. The fake page would then be logged in as the user and could do whatever it wanted.
This was the first thing I thought of as I was listening to the initial discussion.
Using it solely for unimportant account would make it more secure than using Facebook to log into other sites. At least the phisher would only get access as a single session rather than p
Re: (Score:2)
Maybe you should read the spec: https://www.grc.com/sqrl/phishing.htm [grc.com]
It says right on the page that an active attack could be mounted if you use a cross device authentication like you'd use in a public computer setting.
The computer you are accessing the site from it at a phishing site that displays an active QR code to log you into the real site.
Your cellphone you authenticate with is accessing the Internet via a cellular data connection so the IP of the computer and cellphone would be different.
Re: (Score:2)
Try 555-1212.
OTOH, I rarely give my phone #, even if they ask. If they won't take a fictitious one, and don't allow you to skip it, then I just don't go there.
Re: (Score:2)
Since its a login app and not a browser.... the only thing it can do is display what site it thinks you are trying to authenticate to and then authenticate you to it if you say to continue. And all that does is allow the existing session (on the possibly different system) browser connect without requiring further authentication.
MIM and Phishing attacks might be possible, but no more probable or possible than existing login's. And with this system the MIM or Phisher doesn't gain any additional information ab
Re: (Score:2)
The fallacy of the golden mean. The truth doesn't always lie between two extremes. He can be, and has proven to be, careful in his self-education and execution over decades. He nailed Microsoft on open sockets - *yes - he -did* - and figured out Prism as a pipe-tap rather than as a cooperative venture while everyone else was screaming and running in circles, accusing everyone of collaboration (not that there isn't, of course). I've listened to him for years. I've never known anyone so careful of his reasoni
Re: (Score:2)
Indeed no. It doesn't.
Re: (Score:2)
Idiocy indeed. Learn to read.
Re: (Score:2)
Read.
Re: (Score:2)
A web site can still require any authentication it wants, including userid and password. As the proposal states, if you read it.
And, again, and again, and AGAIN, you do not need a smartphone. The challenge can be a generated URL.
Please, help out here, and read the proposal. It's quite clever, and everyone is trying to break it, find the holes. So read those first. Maybe then you can find a new hole, and then someone can get it fixed.