I am unfortunately not bullish that this will pick up but there are strong arguments for this way to authenticate.<p>- you would typically store the private key on a disk-encrypted app-whitelisted iphone, so that the computer you are browsing with, whether yours or a public machine, is never involved in the authentication. Effectively this achieves 2FA. And you don't care if the machine you browse with is compromised.<p>- this does not rely on a third party, it is purely an authentication mechanism. So it removes the risk of that third party tracking you, selling or leaking your data.<p>- it should be fairly practical and easy to use, does not rely on installing anything on the machine you browse with<p>- the website you authenticate to can be hacked, it stores no useful information that can be used by another domain<p>I am not sure Gibson has the audience in the sillicon valley required for this to become mainstream. But the principle makes a lot of sense to me. Of course your are still exposed to the password protecting your private key being stolen, which gives the attacker access to everything, but this is no different from a password manager. Except that unlike a password manager, you do not need to enter that master password on the machine you are browsing with, which considerably reduces the risk.
SQRL has always annoyed me because of Gibson's propensity for presenting this as novel work. QR-based logins have been around for a long time--as with <a href="http://www.zdnet.com/article/open-sesame-googles-no-password-log-in/" rel="nofollow">http://www.zdnet.com/article/open-sesame-googles-no-password...</a>.<p>Of course I don't know what the mechanics of Sesame were, and Gibson does a good job of fleshing out a particular protocol, but this kind of hype seems typical of Gibson.<p>That said, he also overstates the value of SQRL quite a bit, I think. It's certainly a good system for preventing use of passwords--which is valuable in its own right--but his handwaviness around implementation hides some obvious flaws.<p>First, if this is a mobile app--which seems most likely--then we can't actually assume IP sharedness between the app and the login browser, so this is really trivially phishable.<p>Second, if this is client software on the same machine as the browser, why do the silly QR scan thing when you could just have some solid browser integration that actually validates the server SSL cert--and is thus phishing proof--a la FIDO? Hell, even a browser-based password manager is safer against phishing than this, since those at least can validate the domain.<p>It's hard to see in which context QR scanning is preferable to the alternatives already in existence--FIDO, which provides true security, or phone-based "yes/no" assents, which are more usable and equally phishable.
I think this is great, but its time has come and mostly passed in my opinion. The future belongs to FIDO UAF and U2F.<p>They are building a hole ecosystem with all kinds of capability and additional security that SQRL simply can not provide. Most important being anti-phishing protection. They are working on mechanism that would allow you to use the phone as a authenticator even when working on your desktop, this is part of the upcoming version of the standard.<p>They are already very popular and in a lot of hardware, they are working with w3c to standardize, part of the Web Authentication group.<p>Some people wrongly assume that UAF is only about but it could also be somebody entering a password or pin. The main attraction is that it allows for independent evolution of authenticaters without the server having to know or care (he can care if he likes). This will be a game changer.
This is awesome.<p>I just hope that people secure their phones. I recently got a new Android phone and it has no password and no encryption by default, so I assume most people leave it like that.<p>If you get access to my phone you can access 10+ years of pictures, email, bank account, and all the services I use.<p>Besides this, I love it. Can it be implemented in a website, already, or is it just an idea..?
This is actually implemented in the biggest bank of Ukraine, PrivatBank.<p>1. Open login page <a href="https://www.privat24.ua" rel="nofollow">https://www.privat24.ua</a> on the computer, you'll see a QR code,<p>2. Take your phone, open bank's official Privat24 app,<p>3. Within the app select "Scan QR code",<p>4. Upon scanning, the page on the computer is reloaded and you are presented with the dashboard.<p>Very convenient. I wish more services across the internet would provide the same means to log in (although, of course not every one service can afford having a dedicated mobile app).
My bank has been using this for a few years now, and it quickly became my preferred method of logging in. Open the bank app, scan the code, punch in a PIN on the phone and the browser bank opens almost like magic. Very easy to set up for non techies as well.<p><a href="https://secure.skandiabanken.no/Authentication/QRCode" rel="nofollow">https://secure.skandiabanken.no/Authentication/QRCode</a>
Very much comment here on this subject, unfortunately very much of it references out of date or incorrect sources or even misses the point entirely possibly due to the posters not understanding the underlying concepts.<p>I partly blame myself for the first part as I am a contributor to SQRL and have been lax in keeping my part of the documentation current as things progress, Steve has had similar problems.<p>As to the second, SQRL is not a 2FA succinctly it is a:-<p>Single factor (1FA), 2-party, Zero knowledge, pseudonymous proof of identity.<p>The use of QR-Codes was an early feature but is mostly relegated in favour of same device authentication, with I hope a brand new feature (Client Provided Session) that will effectively detect & then eject a MITM attempting a session hijack from the connection.<p>The nature of the 2-party relationship is such that no site can determine without the collusion of the user themselves if that user has an SQRL authenticated account on any other site, hence pseudonymous.<p>Reference implementations require that the Master Identity file is stored in an encrypted form and only decrypted at point of use by a key derived from something only the valid user can provide (passphrase, biometric), thus user to identity is confirmed.<p>Loss of an unprotected Master Identity File exposing the Master Key is not fatal because although the master key will provide the means of access it does not allow an attacker to update site specific keys. There is effectively a Super-Master Key that is never exposed but protected with an exported system generated encryption key that is held offline for such an eventuality.<p>Finally because this is a protocol cooked up by a group of enthusiasts we always welcome constructive input and entities willing to offer support in getting SQRL more widely understood.
Aside from a few cryptographic details (like which elliptic curve to use), this system is identical to [BitId](<a href="https://github.com/bitid/bitid" rel="nofollow">https://github.com/bitid/bitid</a>). BitID is already being deployed in the Bitcoin ecosystem. For instance, you can see it on the buy/sell service [Glidera](<a href="https://www.glidera.io/loginbitidqr" rel="nofollow">https://www.glidera.io/loginbitidqr</a>).<p>One benefit of doing this in the context of Bitcoin is that users already have mobile apps that can manage private keys (with backups) and scan QR codes. With Bitcoin, if you lose your keys, you lose money, so there is a tremendous incentive for both users and wallet authors to get this stuff right. Using the same technology for logging in an easy next step.
Something that I haven't seen mentioned yet is that systems similar to this are already pervasive on the Chinese internet.<p>Here's Taobao's login page: <a href="https://world.taobao.com/markets/all/login" rel="nofollow">https://world.taobao.com/markets/all/login</a><p>And Alipay's: <a href="https://login.aliexpress.com/" rel="nofollow">https://login.aliexpress.com/</a><p>Both have that little QR code icon peeking from the corner. You just click that, open the relevant app on your phone and you're in.
This is truly awesome! But I miss a single source that has everything users and developers need to know.
For SQRL to become mainstraim this is absolutely necessary.
Right now there is <a href="https://www.grc.com/sqrl/sqrl.htm" rel="nofollow">https://www.grc.com/sqrl/sqrl.htm</a> (1), <a href="https://sqrl.pl/" rel="nofollow">https://sqrl.pl/</a> (2) and <a href="https://github.com/vRallev/SQRL-Protocol" rel="nofollow">https://github.com/vRallev/SQRL-Protocol</a> (3) and some other sites.
(1) looks a bit out-of-date in terms of design and has no clear instructions how to integrate it into own websites.
(2) links to (1)
(3) could be more.<p>I am looking for a webpage like this: <a href="http://swagger.io/" rel="nofollow">http://swagger.io/</a>
And this: <a href="https://github.com/swagger-api" rel="nofollow">https://github.com/swagger-api</a><p>Besides, it would be awesome if browser plugins could make SQRL available for sites that don't support SQRL yet.<p>I haven't read the protocol specs yet - does SQRL allow metadata exchange between the authenticating client app and the website?
Especially for registrations this might be very useful. For example, the client could suggest a TTL for the session or provide an email address the website can use to contact the user.
Reminds me of a startup called clef. When I went to link to them, I found they're shutting down:<p><a href="https://getclef.com" rel="nofollow">https://getclef.com</a>
So it says SQRL is "stateless", but I'm still confused. You'd still use cookies or JWTs to implement sessions, right? How do I actually identify the client that I just authenticated? In other words, when the user clicks 'login,' what is actually sent to me, the nonce? Is the url in (this graphic)[<a href="https://www.grc.com/sqrl/sign-algo.png" rel="nofollow">https://www.grc.com/sqrl/sign-algo.png</a>] the login page URL? If so, do I have to use an intermediary cookie to remember which client I sent a given URL to?
I really like the idea, but the time frame of when the protocol will be "complete" seems (as noted by other commenters here and by the fact that it looks to have been posted in 2013) a bit sketchy.
Still, I'm seriously thinking about making server / client libraries for myself and others so this is less of "Here's this really cool idea and a few sort-of complete implementations", and more "Here's this really cool idea, and here's how you can integrate it into your sites if you want".
Check this out - it actually has implementations - <a href="https://securelogin.pw/" rel="nofollow">https://securelogin.pw/</a>
To me, the fatal flaw in SQRL (and options like it) has been MITM (man in the middle) attacks. For instance:<p><a href="https://security.stackexchange.com/a/46205" rel="nofollow">https://security.stackexchange.com/a/46205</a>
No more username, passwords and your are in control. Seems like a perfect protocol for login and authentication.<p>How will it work on mobile only world? Can this also work on iOS and Chrome OS?
Have a look at <a href="https://authme.io" rel="nofollow">https://authme.io</a> - we have both app and SDK for a push notification based authentication.<p>Do have a look at
<a href="https://medium.com/@shardul.citrus/passwords-bad-ux-security-loopholes" rel="nofollow">https://medium.com/@shardul.citrus/passwords-bad-ux-security...</a><p>P.s. I work for AuthMe.
This was posted about 4 years ago, and it was half baked and fully attacked by wherever I saw it posted.<p>I was quite annoyed by it because I had a similar idea that addressed some of this scheme's weaknesses that I was developing before this was released (half baked!), and the negative attention this brought wasn't going to create a warm welcome for my concept, so I dropped it.
This can be instantly disregarded because Steve Gibson is a charlatan. He's got a history of getting things wrong as loudly as possible in order to generate reputation. <a href="http://attrition.org/errata/charlatan/steve_gibson/" rel="nofollow">http://attrition.org/errata/charlatan/steve_gibson/</a>