Catch up on stories from the past week (and beyond) at the Slashdot story archive

 



Forgot your password?
typodupeerror
×
Image

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."
This discussion has been archived. No new comments can be posted.

New Standard For Website Authentication Proposed: SQRL (Secure QR Login)

Comments Filter:
  • by Anonymous Coward

    So, basically... challenge/response tunneled inside of SSL, but with a QR code? Quick, get the patent office on the phone.

    • by Seumas ( 6865 ) on Thursday October 17, 2013 @05:34PM (#45158497)

      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.

      • Even if Mr. Gibson did seek a patent, Google has prior art [zdnet.com].
        • Re: (Score:3, Interesting)

          by radarskiy ( 2874255 )

          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/)

  • by SilentConsole ( 985427 ) on Thursday October 17, 2013 @05:18PM (#45158321)
    I don't think it will be very popular to force user to pull out a smart-phone ( or even HAVE a smart phone ) to use a website.
    • by w_dragon ( 1802458 ) on Thursday October 17, 2013 @05:21PM (#45158347)
      Or just create a browser plugin that will read a QR and open a new tab to the link. No smartphone required. Of course, that kind of highlights why it's a dumb idea anyway.
      • Re: (Score:2, Insightful)

        by Anonymous Coward

        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 ;-)

    • Reading more fully - there is a suggestion for providing a clickable link as well from a desktop - so, tying identity uniquely to a device is actually the intent here, still not a great user experience.
    • Re: (Score:2, Interesting)

      by postbigbang ( 761081 )

      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.

      • by tlhIngan ( 30335 )

        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.

        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.

        Actually, two smartphones required to browse. One to navigate to the website, the other to take the pict

      • I can see this being useful where your physical location is already known, e.g. Online banking / purchasing. I don't care if my bank knows I'm signing in from my home; They already know where I live. I have a mortgage with them.
    • 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.

  • 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?
    • by Joining Yet Again ( 2992179 ) on Thursday October 17, 2013 @05:26PM (#45158397)

      Are there people who still carry only one 'phone around? And yet people rely on them so much.....

    • by Seumas ( 6865 )

      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.

    • 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>

    • 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.

      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

  • 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.

    • by Seumas ( 6865 )

      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.

      • by Joining Yet Again ( 2992179 ) on Thursday October 17, 2013 @05:37PM (#45158539)

        "MySQL" is pronounced "Why aren't you using PostgreSQL?"

        And "noSQL" is pronounced "no".

      • 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.

      • I've always pronounced it Post-Grey-Sequel

    • 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.

  • 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.

  • Isn't this exactly what happens during SSL client certificate authentication? Modulo routing the response through a smartphone, that is.

    • 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

      • 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 (

  • by Teun ( 17872 ) on Thursday October 17, 2013 @05:31PM (#45158457)
    I assume this will be enabled between Friday October 18, 8 pm to Saturday October 19, 1 am (Eastern Time).
  • Wow. (Score:4, Funny)

    by bennomatic ( 691188 ) on Thursday October 17, 2013 @05:31PM (#45158465) Homepage
    You had me at "QR code".
  • If you want secure / two-factor today then you'll use Google Authenticator - which is what all bitcoin exchanges use. It's the standard. We don't need a new one. And it's open, so you don't need a smartphone, you can use a PC version like JAuth. This QR code thing is less smart as it would need you to actually have a smartphone - and that's a very dumb idea. The Google Authenticator standard does not, but you should use a another device (notebook computer, tablet, phone, whatever) for it since that's more s
  • They already exist and are supported, doing pretty much the same thing on a secondary device does little to improve things.

    • 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.

      • 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

      • 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.

        • 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.

          • Typo well not dell. Your ok with putting you username/pass into something but not connecting a heavily secured computer on a usb stick?

            • 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.

      • Yah! I'm authenticated on a public computer that may be compromised! Now the compromised machine can act as me! You're a moron.

    • As I understand it, it's intended in part for the use case where you browse on a computer that's not your own, such as at a relative's home or a public library. This means you haven't stored a client certificate on this computer. The authenticator app on your smartphone would store its own equivalent of a client certificate.
      • 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?

        • by tepples ( 727027 )

          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.

  • by WaffleMonster ( 969671 ) on Thursday October 17, 2013 @05:55PM (#45158711)

    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.

    • 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.

  • 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!

  • 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

  • ...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.

    • 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

  • 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

  • So, how do I snap the QR code - if I am logging into the website - on my phone...?
  • 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"

One person's error is another person's data.

Working...