13 ms·

SQRL – Secure Quick Reliable Login

213 points by sr2 9y ago

joschkadev 9y ago
https://tillmanns.me/authentication.html https://tillmanns.me/authentication.html
falsedan 9y ago
Why does this need an app? Looks like it would work just as well with a browser extension reading the QR code.
- arnoooooo 9y ago
  Actually the QR code is not even needed then. It's just browser-generated ids/keys.
  - cm2187 9y ago
    But there is a strong argument for storing the private key on a different machine, particularly a disk-encrypted, app-whitelisted iphone, rather than on an open platform likely full of malware and telemetry like a mac or a pc. Then you need a way for your 2FA device to interact with the browser to do the login for you. A QR code is as good as another method.
    - falsedan 9y ago
      What about a smart card then?
      - cm2187 9y ago
        Even better except that now you have to carry it around everywhere.
  - floatboth 9y ago
    The QR code just makes signing in with a different device possible. With SQRL, the QR code is supposed to be clickable for when you're browsing on your smartphone and want to sign in with the app that's on it.
- borplk 9y ago
  It's not that simple. It needs an app to store/manage your identity. It is however a protocol so it's possible to have many different clients for it.
  - falsedan 9y ago
    Same question but now the browser is using local storage?
    - borplk 9y ago
      Can you clarify what you mean?
- wscott 9y ago
  It can work that way and is described right below the xkcd comic. He does it with a separate process running on the local machine and the javascript uses a localhost connection to talk with it.
tdeck 9y ago
Reminds me of a startup called clef. When I went to link to them, I found they're shutting down: https://getclef.com https://getclef.com
- laurent123456 9y ago
  I guess this kind of technology will pick up once Facebook or Google adopt it (or, more likely, develop their own).
cm2187 9y ago
I am unfortunately not bullish that this will pick up but there are strong arguments for this way to authenticate. - 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. - 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. - it should be fairly practical and easy to use, does not rely on installing anything on the machine you browse with - the website you authenticate to can be hacked, it stores no useful information that can be used by another domain 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.
- cormacrelf 9y ago
  There's a slight problem. It doesn't 'effectively' achieve 2FA at all. If I lose my phone and lose my master key, I lose my all my identities, and even if I somehow remember them, I can't prove they are mine. HMAC(Master key + Domain) -> private key + identity (public key) HMAC(Master key + Domain) + challenge -> response Lose that master key, and you can't get anywhere. By contrast, FIDO U2F works loosely like this: 1. first factor 2. HMAC(Master key + Domain) + challenge -> response Key point being that it's still 2FA, where SQRL is still just one factor. If you lose your FIDO device, at least as it stands, most sites make you have a token generator app as well, or at least a path through customer support. It may help to think of an email + password as being two factors, and various 2FA solutions actually being three factors. Email is something you can prove independently of your password. SQRL has exactly one factor, and zero failover strategy. It's debatable whether it should be possible to get through customer support after losing anything, but the 99% of online security infrastructure that builds a chain of trust upon your email address really does work for most people in most cases. It's terrible that email addresses are easily correlated across different websites, but the reality is that any replacement identity solution needs to be as easily restored in case of failure. For SQRL to work and give you an out for lost master keys, it would need at least a way of creating a redundancy, like replacing HMAC(Master key + Domain) with an asymmetric negotiation of the correct identity, or adding another layer of indirection that makes the master key replaceable.
deleted 9y ago
[deleted]
shardullavekar 9y ago
Have a look at https://authme.io https://authme.io - we have both app and SDK for a push notification based authentication. Do have a look at https://medium.com/@shardul.citrus/passwords-bad-ux-security-loopholes https://medium.com/@shardul.citrus/passwords-bad-ux-security... P.s. I work for AuthMe.
- nextlevelwizard 9y ago
  Seriously what even are you offering? Your web site doesn't tell me anything. Everything is just "pattern lock" that and "pattern lock" this. Are you just substituting passwords with freaking 9 point "pattern lock"? Because that sounds super dangerous and weakens security significantly (and it's not like people are going to use different patterns for all websites/services anyway) Also your signup says "no credit card required" are you asking money for this? Because as far as I'm aware SQRL is completely free to use.
  - cormacrelf 9y ago
    Not to mention authme.io redirects to authme.authme.authme.host. I love it.
    - stapled_socks 9y ago
      That's pretty odd. I struggle to see the point. Certainly didn't help establish trust in the service.
  - shardullavekar 9y ago
    We offer a seamless way of logging in: both on smartphones (Android) and Websites. App developers integrate AuthMe and instead of passwords, ask for setting a 4 X 4 pattern on which we profile user behaviour. Every time a user has to log in, they have to enter the same pattern and AuthMe offers a behavioural score of the user. (Download our Android app and see the trust scores if you can.) On the website, users enter their primary key and get a push notification prompt to log in with the 4 X 4 pattern lock. Just a pattern lock? Of course not! We profile users on a set of 12 behavioural characters which are difficult to copy. Developers have a choice to disable to behavioural auth part - in which case we are free too. We charge only when you enable behavioural auth. Hope you try the product.
chaz6 9y ago
Does this have the facility to choose an identity when logging in since you may have more than 1 account on a site?
- cm2187 9y ago
  I think you can achieve that in the SQRL app (I don't know if it does in practice). The app would have multiple private keys with one flagged as active. You would toggle which is active before reading the QR code (or tapping on it if on the same device).
  - borplk 9y ago
    I believe technically it "computes" the private key on the fly as you need it (it's derived from the master key plus other factors to make it unique per site/user).
- ipottinger 9y ago
  A user inputted string can be provided at login. Together, the master-key, the inputted string, and the site domain are combined to regenerate the site-specific public-key private-key for that sub-identity.
jelv 9y ago
No more username, passwords and your are in control. Seems like a perfect protocol for login and authentication. How will it work on mobile only world? Can this also work on iOS and Chrome OS?
- cm2187 9y ago
  You would typically store the private key on a single device to reduce the risk of leaking it. Authentication on another device is done through the QR code. Authentication on the same device is done through the SQRL app registering a protocol. So you tap on the QR code, it opens a SQRL:// url which opens in the SQRL app, the app authenticates, the websites redirects you to the desired authenticated page.
  - jelv 9y ago
    So my ID's are in my SQRL app on my laptop or phone. Can I sync my ID's between my laptop and phone? I don't want to be forced to use my phone to scan a QR code on screen for every site.. Can 1Password implement SQRL?
    - cm2187 9y ago
      I don't know about the particulars of the app, but at the end of the day, the only data stored in the SQRL app is the private key. All website specific keys are derived from a combination of the domain of that website and of the private key. So there is no need for a sync mechanism per se, outside of originally sharing the private key. That being said storing that key on your (encrypted) mobile only is what protects you. There is an option to maintain the state of which websites were used to authenticate, but that's only to reset your access should your private key be compromised (or mobile stolen). Then your SQRL app should sync the list of websites with some central location. This would ensure that the day you think the key is compromised, you can reset all access to all websites with a new private key automatically (this is part of the SQRL protocol). On 1Password, I don't see why not. Gibson made the protocol open source and free.
nkkollaw 9y ago
This is awesome. 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. If you get access to my phone you can access 10+ years of pictures, email, bank account, and all the services I use. Besides this, I love it. Can it be implemented in a website, already, or is it just an idea..?
- jelv 9y ago
  It's not released at this moment. But it will be released soon™. Also there are already a few examples in the wild (WordPress plugin, Android lib, etc) here: https://www.grc.com/sqrl/implementations.htm https://www.grc.com/sqrl/implementations.htm
  - nkkollaw 9y ago
    But... I read in the comments that it's from 2013..? It will never be released I guess, then. https://securelogin.pw https://securelogin.pw as another user suggested might be a better alternative, then. Too bad, I really liked the name.
    - Cyphase 9y ago
      It has been in development since 2013, but it still is under active development, and is probably(?) going to be released relatively(?) soon.
4e1a 9y ago
I have a backup of my SQRL keys for when this goes mainstream. I really like the idea, but am not hopeful it will become widely adopted.
chuckdries 9y ago
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)[https://www.grc.com/sqrl/sign-algo.png https://www.grc.com/sqrl/sign-algo.png] the login page URL? If so, do I have to use an intermediary cookie to remember which client I sent a given URL to?
- laurent123456 9y ago
  I think he means that the authentication process itself is stateless, as you don't need to store any usernames or passwords. I don't think you even need to store the nonce since it will still be on the page by the time the authentication process is complete.
  - cm2187 9y ago
    What I think they mean by stateless is that the private key used for the website is derived from the master private key and the domain name of the website. So the only state to maintain is the master private key. There is no need to maintain a list of what key was used for what website.
    - paulryanrogers 9y ago
      Which is its greatest weakness IMO since a compromise of the master key means all accounts using that key are vulnerable. And one doesn't need the key database to get it. It could be guessed. With passwords an attacker has to guess each site independently, or gain access to the password database and the decryption password. IIRC the SQRL file itself is like a database of master keys so one can change them in an orderly way. But the idea is to have only one, or a few.
      - floatboth 9y ago
        That's a common criticism of any stateless system, like the Master Password algorithm. I made https://github.com/myfreeweb/freepass https://github.com/myfreeweb/freepass which is based on that algorithm but also generates keys, not just passwords — Ed25519 keys for SSH, signify, and I wanted to add SQRL but haven't got around to that yet. Some people like to say that "omg if your master password gets stolen with this, that's it, but with a classic file-based password manager they also have to steal the database file". However… If the stealing happens via keylogger malware, THAT MALWARE CAN ALSO STEAL THE DB FILE, for fuck's sake. If the stealing happens via someone looking over your shoulder / recording how you enter the password with a surveillance camera, they also have to know your "full name" which can be whatever string you want, it's stored on your device and isn't visible when entering the password.
nickik 9y ago
I think this is great, but its time has come and mostly passed in my opinion. The future belongs to FIDO UAF and U2F. 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. They are already very popular and in a lot of hardware, they are working with w3c to standardize, part of the Web Authentication group. 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.
- vim_wannabe 9y ago
  Is FIDO something that I can use instead of implementing email+password register/validate_email/change_password/reset_password/change_email over and over again? Is it finally here, what Persona promised us?
  - nickik 9y ago
    No. FIDO 1.0 and FIDO 1.1 are more narrow in scope. This is not a federated login system. These are point-to-point authentication protocols that don't involve any third party. It is a replacement specifically to replace password login and multiple second factor solutions. It will make it far easier to implement registration and authentication but not radically, you still have to do it. It will also not replace your recovery flow. How to handle recovery is still up to you. FIDO 2.0 will add some notion of tying together different authentications but still not solve the problem of federation (as far as I know). For Federation OpenId Connect is still the best, if not optimal solution.
- homakov 9y ago
  I don't know what kind of future you're talking about. U2F gained 0 adoption and are doomed. What did they expect with $19 sticks that require USB?
deleted 9y ago
[deleted]
Gehinnn 9y ago
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 https://www.grc.com/sqrl/sqrl.htm https://www.grc.com/sqrl/sqrl.htm (1), https://sqrl.pl/ https://sqrl.pl/ (2) and https://github.com/vRallev/SQRL-Protocol https://github.com/vRallev/SQRL-Protocol (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. I am looking for a webpage like this: http://swagger.io/ http://swagger.io/ And this: https://github.com/swagger-api https://github.com/swagger-api Besides, it would be awesome if browser plugins could make SQRL available for sites that don't support SQRL yet. 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.
ConfucianNardin 9y ago
Note: This was first published in 2013 (or maybe even earlier). It hasn't gained traction since, so it seems unlikely it ever will.
- jelv 9y ago
  The development started in 2013, but it's, at this moment, not finished. Steve Gibson commented that it's almost complete and is just working on the documentation. So it's not that weird that it's not adopted in mainstream sites.
  - borplk 9y ago
    I'm a fan of it but I doubt it will gain traction just because it's a little unfriendly for businesses dealing with average Joes who can't be trusted to take full responsibility.
  - wscott 9y ago
    Steve is writing an official reference implementation for Windows. He is trying to get everything right and updates the spec with what he learns. I believe there are other unofficial implementations currently.
  - torgoguys 9y ago
    Just commenting on timing here, not the pros/cons of SQRL, which is a whole other discussion: It's been "almost done" for a long time now. At Gibson's 2014 digicert presentation, he said he would be able to demo it in about a week. Nope, that initial demo didn't happen for another 6 months, IIRC. Shortly after that demo--we're talking June 2015--the Windows client was (checking transcript) "almost finished." Today is exactly TWO YEARS TO-THE-DAY later, and I don't think the client is yet complete. I'm all for doing something right, and that's his stated reason for why it's taking so long, but it also means that based on past history, you should take his time estimates with a HUGE grain of salt. He's slow--it has been nearly 200 weeks of time where he claims he has been working on this more-or-less "non-stop" and that it has been his "focus."
    - 9y ago
homakov 9y ago
Check this out - it actually has implementations - https://securelogin.pw/ https://securelogin.pw/
HurrdurrHodor 9y ago
A more viable competitor: https://www.n-auth.com/ https://www.n-auth.com/
- cm2187 9y ago
  But this is a commercial solution. SQRL is an open source / free protocol.
daveio 9y ago
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. http://attrition.org/errata/charlatan/steve_gibson/ http://attrition.org/errata/charlatan/steve_gibson/
- cm2187 9y ago
  You can question the implementation. But I think the underlying idea is sound. And it shouldn't matter who introduces the idea.
- towerbabbel 9y ago
  It seems to be one of the immutable laws of the internet that whenever there is a discussion of anything related to Steve Gibson someone will invariably post the link to that attrition.org site. If I may disregard the entire Ad hominem part and instead focus on the people posting the link. I must wonder how many have actually read what the site says about Steve Gibson and given some thought to what it might mean. It records a dozen or so issues over a the last 17 years. He has been doing the Security Now podcast since summer of 2005. That is a two hour podcast, 50 episodes a year for twelve year. That is 1200 hours of content. That is like 40 books worth. Then there is also the columns he has written and so on. 40 books attempting to explain security issues to a wider audience with only a dozen errors seems an amazingly low error rate to me. If you also look at what sort of errors are reported you see that some of them seem to be more the errors of degree, rather than kind. He seems to have a tendency to blow things out of proportion; for hyperbole. But if hyperbole is such a deadly sin, why is their go to reference for Steve Gibson errors The Register?!? Now I'm sure Steve Gibson has made more mistakes than those, and the he holds silly opinions on some things. Everyone does. But that attrition.org page does not seem to convince me of anything aside from making me lower my esteem for the attrition.org site. I do wish that rather than this sort utterly lame Ad hominem attacks proposals were judged on their own merit, but this is the internet, so maybe I shouldn't hope for too much.
  - borplk 9y ago
    I wrote an almost identical comment to yours last time there was some discussion about SQRL and Steve and someone mentioned the same thing (your comment is more complete). I think people have just bookmarked that page and copy-paste it as soon as someone mentions him. Let it go people. He and Leo have done a wonderful service with Security Now for the community for more than a decade. The quality of his content is better than what you can find in many universities and it's available to everyone for free. Can we have any of you go on public record every week for 12 years and see how you do? Really unnecessary and undeserved personal attacks ... gets old.
rs232 9y ago
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. https://secure.skandiabanken.no/Authentication/QRCode https://secure.skandiabanken.no/Authentication/QRCode
- kennydude 9y ago
  Sounds a lot better than UK banks with their stupid "enter the third, fifth and seventh characters of your password" which is frustrating
  - mbreese 9y ago
    It also makes you wonder how they know what the third, fifth, or seventh characters of your password are... I suppose they could create multiple hashes each time you change your password, but I'm not optimistic.
    - kennydude 9y ago
      It's more than likely plaintext or "encrypted" (and decrypted to check if it's correct)
    - LiquidFlux 9y ago
      I suspect it may be more related to being keylogged or an equivalent, and not revealing your entire password in the process.
    - arethuza 9y ago
      My UK bank requires a password and a separate secret phrase that they do the letter selection from. You need to supply the password and 3 letters from your secret phrase. As my phrase is quite long I pretty much always end up writing it down or using an editor.... :-)
      - 9y ago
eugene_pirogov 9y ago
This is actually implemented in the biggest bank of Ukraine, PrivatBank. 1. Open login page https://www.privat24.ua https://www.privat24.ua on the computer, you'll see a QR code, 2. Take your phone, open bank's official Privat24 app, 3. Within the app select "Scan QR code", 4. Upon scanning, the page on the computer is reloaded and you are presented with the dashboard. 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).
- wink 9y ago
  Sounds awesome, whereas my German bank still doesn't allow proper passwords, only "PINs" no longer than 5 characters. Fun fact, you can change your login though, it can be 15 characters including non-alphanumeric. /s
  - elcapitan 9y ago
    Which German bank is that?
    - cygned 9y ago
      I know about one. Three other banks where I have accounts, users are allowed to use passwords with a maximum length of 16 characters, which are also restricted in the way that you cannot choose freely. Things like & or { are usually forbidden.
    - wink 9y ago
      Stadtsparkasse München - and I'm not sure if the other Sparkassen are better. Maybe some are, you never know what exactly they share and what's different.
- simooooo 9y ago
  WhatsApp does this too but I don't think its the same as SQRL, as it is a 3rd party doing the work.
- deleted 9y ago
sametmax 9y ago
But if somebody steals your unlocked phone the person can connect to your bank ?
- vim_wannabe 9y ago
  I'm guessing it depends on the client. Most security oriented software on iPhone at least ask for unlock code or Touch ID when opening the app.
  - falcolas 9y ago
    You typically have to set a security code first, before those can be requested. My memory of setting up a new phone is rusty, but I don't recall this being a required step.
- ipottinger 9y ago
  As an aside, please note that the use of a phone and the scanning of a QR code when using SQRL has been more recently relegated to an edge case. The vast majority of users will never do so. SQRL has its own sqrl:// schema.
Numberwang 9y ago
For those in Sweden(and maybe elsewhere), is this similar in any way to the method BankID uses?
- theninth 9y ago
  By BankID I think you are referring to "mobilt BankId"? They are both providing 2FA, but that is where the similarities end. They solves completely different problems. If you use an e-mail-adress (and a password of course) to login on multiple sites, anyone with access to those sites databases could check which services you uses and they could collect all data from all of those databases to get alot of information about you. Mobilt BankId is like that but worse from a privacy perspective. It make sites (I think, someone correct me if I'm wrong) able get, not only the information you provided, but also tie that to your real life identity. That's great for Skatteverket and Försäkringskassan, but for "Random Hacker Forum", it might not be that great. SQRL will not in itself reveal anything about your identity. Even if you use SQRL to login in on different sites and someone had access to all of those sites databases they would not be able to see that you use the same SQRL-identity to login. Also, BankID is relying on a third party for authentication where SQRL is not.
khana 9y ago
I'm all in. I listen to SG's podcast and he is excellent and knows computers at an assembly level.
midnitewarrior 9y ago
This was posted about 4 years ago, and it was half baked and fully attacked by wherever I saw it posted. 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.
s_tec 9y ago
Aside from a few cryptographic details (like which elliptic curve to use), this system is identical to [BitId](https://github.com/bitid/bitid https://github.com/bitid/bitid). BitID is already being deployed in the Bitcoin ecosystem. For instance, you can see it on the buy/sell service [Glidera](https://www.glidera.io/loginbitidqr https://www.glidera.io/loginbitidqr). 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.
Veratyr 9y ago
Something that I haven't seen mentioned yet is that systems similar to this are already pervasive on the Chinese internet. Here's Taobao's login page: https://world.taobao.com/markets/all/login https://world.taobao.com/markets/all/login And Alipay's: https://login.aliexpress.com/ https://login.aliexpress.com/ 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.
- md_ 9y ago
  Flipboard also uses QRs. But to be accurate, this is a convenience feature, not a security feature. It's still phishable.
- zxcvbn4038 9y ago
  Very cool, but it looks like everybody is doing their own thing, no interoperability. =(
md_ 9y ago
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 http://www.zdnet.com/article/open-sesame-googles-no-password-log-in/ http://www.zdnet.com/article/open-sesame-googles-no-password.... 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. 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. 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. 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. 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.
ramriot 9y ago
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. 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. As to the second, SQRL is not a 2FA succinctly it is a:- Single factor (1FA), 2-party, Zero knowledge, pseudonymous proof of identity. 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. 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. 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. 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. 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.
davidkhess 9y ago
To me, the fatal flaw in SQRL (and options like it) has been MITM (man in the middle) attacks. For instance: https://security.stackexchange.com/a/46205 https://security.stackexchange.com/a/46205
- ramriot 9y ago
  Which would make it no worse in that respect than anything else & in many respects much better, please Note: https://news.ycombinator.com/item?id=14472929 https://news.ycombinator.com/item?id=14472929 The use of remote QR-Code authentication is no longer a key feature here, the expectation is that it will almost never be used unless for exceptional circumstances.
  - davidkhess 9y ago
    Can you expand on what "Client Provided Session" means?
    - ramriot 9y ago
      Very simply: In the browser session authentication use case, as well as a sqrl:// scheme link being launched the browser makes a parallel internal probe and then direct GET request to http://127.0.0.1 http://127.0.0.1 on port 25519 which is locked by the local client the payload of the original link base64URL is encoded in the url, which hands over control of what follows to the client application. The client performs authentication as normal, but instead of the session being updated via a browser push a redirection response is returned to it via the client which leads to a single use very temporary and unguessable link that kicks off the authenticated session. Because of browsers same origin policies and other security protections we believe it is not possible for an MITM attacker actively tunneling a valid SQRL login page to gain access to this information. Clearly this does rely on the browser agent upholding strict security policies, but then if it did not you would have much bigger problems.
      - davidkhess 9y ago
oliver2213 9y ago
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".

213 points by sr2 9y ago

joschkadev 9y ago

https://tillmanns.me/authentication.html https://tillmanns.me/authentication.html

falsedan 9y ago

Why does this need an app? Looks like it would work just as well with a browser extension reading the QR code.

arnoooooo 9y ago
Actually the QR code is not even needed then. It's just browser-generated ids/keys.
- cm2187 9y ago
  But there is a strong argument for storing the private key on a different machine, particularly a disk-encrypted, app-whitelisted iphone, rather than on an open platform likely full of malware and telemetry like a mac or a pc. Then you need a way for your 2FA device to interact with the browser to do the login for you. A QR code is as good as another method.
  - falsedan 9y ago
    What about a smart card then?
    - cm2187 9y ago
      Even better except that now you have to carry it around everywhere.
- floatboth 9y ago
  The QR code just makes signing in with a different device possible. With SQRL, the QR code is supposed to be clickable for when you're browsing on your smartphone and want to sign in with the app that's on it.
borplk 9y ago
It's not that simple. It needs an app to store/manage your identity. It is however a protocol so it's possible to have many different clients for it.
- falsedan 9y ago
  Same question but now the browser is using local storage?
  - borplk 9y ago
    Can you clarify what you mean?
wscott 9y ago
It can work that way and is described right below the xkcd comic. He does it with a separate process running on the local machine and the javascript uses a localhost connection to talk with it.

tdeck 9y ago

Reminds me of a startup called clef. When I went to link to them, I found they're shutting down: https://getclef.com https://getclef.com

laurent123456 9y ago
I guess this kind of technology will pick up once Facebook or Google adopt it (or, more likely, develop their own).

cm2187 9y ago

I am unfortunately not bullish that this will pick up but there are strong arguments for this way to authenticate. - 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. - 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. - it should be fairly practical and easy to use, does not rely on installing anything on the machine you browse with - the website you authenticate to can be hacked, it stores no useful information that can be used by another domain 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.

cormacrelf 9y ago
There's a slight problem. It doesn't 'effectively' achieve 2FA at all. If I lose my phone and lose my master key, I lose my all my identities, and even if I somehow remember them, I can't prove they are mine. HMAC(Master key + Domain) -> private key + identity (public key) HMAC(Master key + Domain) + challenge -> response Lose that master key, and you can't get anywhere. By contrast, FIDO U2F works loosely like this: 1. first factor 2. HMAC(Master key + Domain) + challenge -> response Key point being that it's still 2FA, where SQRL is still just one factor. If you lose your FIDO device, at least as it stands, most sites make you have a token generator app as well, or at least a path through customer support. It may help to think of an email + password as being two factors, and various 2FA solutions actually being three factors. Email is something you can prove independently of your password. SQRL has exactly one factor, and zero failover strategy. It's debatable whether it should be possible to get through customer support after losing anything, but the 99% of online security infrastructure that builds a chain of trust upon your email address really does work for most people in most cases. It's terrible that email addresses are easily correlated across different websites, but the reality is that any replacement identity solution needs to be as easily restored in case of failure. For SQRL to work and give you an out for lost master keys, it would need at least a way of creating a redundancy, like replacing HMAC(Master key + Domain) with an asymmetric negotiation of the correct identity, or adding another layer of indirection that makes the master key replaceable.

deleted 9y ago

[deleted]

shardullavekar 9y ago

Have a look at https://authme.io https://authme.io - we have both app and SDK for a push notification based authentication. Do have a look at https://medium.com/@shardul.citrus/passwords-bad-ux-security-loopholes https://medium.com/@shardul.citrus/passwords-bad-ux-security... P.s. I work for AuthMe.

nextlevelwizard 9y ago
Seriously what even are you offering? Your web site doesn't tell me anything. Everything is just "pattern lock" that and "pattern lock" this. Are you just substituting passwords with freaking 9 point "pattern lock"? Because that sounds super dangerous and weakens security significantly (and it's not like people are going to use different patterns for all websites/services anyway) Also your signup says "no credit card required" are you asking money for this? Because as far as I'm aware SQRL is completely free to use.
- cormacrelf 9y ago
  Not to mention authme.io redirects to authme.authme.authme.host. I love it.
  - stapled_socks 9y ago
    That's pretty odd. I struggle to see the point. Certainly didn't help establish trust in the service.
- shardullavekar 9y ago
  We offer a seamless way of logging in: both on smartphones (Android) and Websites. App developers integrate AuthMe and instead of passwords, ask for setting a 4 X 4 pattern on which we profile user behaviour. Every time a user has to log in, they have to enter the same pattern and AuthMe offers a behavioural score of the user. (Download our Android app and see the trust scores if you can.) On the website, users enter their primary key and get a push notification prompt to log in with the 4 X 4 pattern lock. Just a pattern lock? Of course not! We profile users on a set of 12 behavioural characters which are difficult to copy. Developers have a choice to disable to behavioural auth part - in which case we are free too. We charge only when you enable behavioural auth. Hope you try the product.

chaz6 9y ago

Does this have the facility to choose an identity when logging in since you may have more than 1 account on a site?

cm2187 9y ago
I think you can achieve that in the SQRL app (I don't know if it does in practice). The app would have multiple private keys with one flagged as active. You would toggle which is active before reading the QR code (or tapping on it if on the same device).
- borplk 9y ago
  I believe technically it "computes" the private key on the fly as you need it (it's derived from the master key plus other factors to make it unique per site/user).
ipottinger 9y ago
A user inputted string can be provided at login. Together, the master-key, the inputted string, and the site domain are combined to regenerate the site-specific public-key private-key for that sub-identity.

jelv 9y ago

No more username, passwords and your are in control. Seems like a perfect protocol for login and authentication. How will it work on mobile only world? Can this also work on iOS and Chrome OS?

cm2187 9y ago
You would typically store the private key on a single device to reduce the risk of leaking it. Authentication on another device is done through the QR code. Authentication on the same device is done through the SQRL app registering a protocol. So you tap on the QR code, it opens a SQRL:// url which opens in the SQRL app, the app authenticates, the websites redirects you to the desired authenticated page.
- jelv 9y ago
  So my ID's are in my SQRL app on my laptop or phone. Can I sync my ID's between my laptop and phone? I don't want to be forced to use my phone to scan a QR code on screen for every site.. Can 1Password implement SQRL?
  - cm2187 9y ago
    I don't know about the particulars of the app, but at the end of the day, the only data stored in the SQRL app is the private key. All website specific keys are derived from a combination of the domain of that website and of the private key. So there is no need for a sync mechanism per se, outside of originally sharing the private key. That being said storing that key on your (encrypted) mobile only is what protects you. There is an option to maintain the state of which websites were used to authenticate, but that's only to reset your access should your private key be compromised (or mobile stolen). Then your SQRL app should sync the list of websites with some central location. This would ensure that the day you think the key is compromised, you can reset all access to all websites with a new private key automatically (this is part of the SQRL protocol). On 1Password, I don't see why not. Gibson made the protocol open source and free.

nkkollaw 9y ago

This is awesome. 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. If you get access to my phone you can access 10+ years of pictures, email, bank account, and all the services I use. Besides this, I love it. Can it be implemented in a website, already, or is it just an idea..?

jelv 9y ago
It's not released at this moment. But it will be released soon™. Also there are already a few examples in the wild (WordPress plugin, Android lib, etc) here: https://www.grc.com/sqrl/implementations.htm https://www.grc.com/sqrl/implementations.htm
- nkkollaw 9y ago
  But... I read in the comments that it's from 2013..? It will never be released I guess, then. https://securelogin.pw https://securelogin.pw as another user suggested might be a better alternative, then. Too bad, I really liked the name.
  - Cyphase 9y ago
    It has been in development since 2013, but it still is under active development, and is probably(?) going to be released relatively(?) soon.

4e1a 9y ago

I have a backup of my SQRL keys for when this goes mainstream. I really like the idea, but am not hopeful it will become widely adopted.

chuckdries 9y ago

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)[https://www.grc.com/sqrl/sign-algo.png https://www.grc.com/sqrl/sign-algo.png] the login page URL? If so, do I have to use an intermediary cookie to remember which client I sent a given URL to?

laurent123456 9y ago
I think he means that the authentication process itself is stateless, as you don't need to store any usernames or passwords. I don't think you even need to store the nonce since it will still be on the page by the time the authentication process is complete.
- cm2187 9y ago
  What I think they mean by stateless is that the private key used for the website is derived from the master private key and the domain name of the website. So the only state to maintain is the master private key. There is no need to maintain a list of what key was used for what website.
  - paulryanrogers 9y ago
    Which is its greatest weakness IMO since a compromise of the master key means all accounts using that key are vulnerable. And one doesn't need the key database to get it. It could be guessed. With passwords an attacker has to guess each site independently, or gain access to the password database and the decryption password. IIRC the SQRL file itself is like a database of master keys so one can change them in an orderly way. But the idea is to have only one, or a few.
    - floatboth 9y ago
      That's a common criticism of any stateless system, like the Master Password algorithm. I made https://github.com/myfreeweb/freepass https://github.com/myfreeweb/freepass which is based on that algorithm but also generates keys, not just passwords — Ed25519 keys for SSH, signify, and I wanted to add SQRL but haven't got around to that yet. Some people like to say that "omg if your master password gets stolen with this, that's it, but with a classic file-based password manager they also have to steal the database file". However… If the stealing happens via keylogger malware, THAT MALWARE CAN ALSO STEAL THE DB FILE, for fuck's sake. If the stealing happens via someone looking over your shoulder / recording how you enter the password with a surveillance camera, they also have to know your "full name" which can be whatever string you want, it's stored on your device and isn't visible when entering the password.

nickik 9y ago

I think this is great, but its time has come and mostly passed in my opinion. The future belongs to FIDO UAF and U2F. 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. They are already very popular and in a lot of hardware, they are working with w3c to standardize, part of the Web Authentication group. 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.

vim_wannabe 9y ago
Is FIDO something that I can use instead of implementing email+password register/validate_email/change_password/reset_password/change_email over and over again? Is it finally here, what Persona promised us?
- nickik 9y ago
  No. FIDO 1.0 and FIDO 1.1 are more narrow in scope. This is not a federated login system. These are point-to-point authentication protocols that don't involve any third party. It is a replacement specifically to replace password login and multiple second factor solutions. It will make it far easier to implement registration and authentication but not radically, you still have to do it. It will also not replace your recovery flow. How to handle recovery is still up to you. FIDO 2.0 will add some notion of tying together different authentications but still not solve the problem of federation (as far as I know). For Federation OpenId Connect is still the best, if not optimal solution.
homakov 9y ago
I don't know what kind of future you're talking about. U2F gained 0 adoption and are doomed. What did they expect with $19 sticks that require USB?

deleted 9y ago

[deleted]

Gehinnn 9y ago

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 https://www.grc.com/sqrl/sqrl.htm https://www.grc.com/sqrl/sqrl.htm (1), https://sqrl.pl/ https://sqrl.pl/ (2) and https://github.com/vRallev/SQRL-Protocol https://github.com/vRallev/SQRL-Protocol (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. I am looking for a webpage like this: http://swagger.io/ http://swagger.io/ And this: https://github.com/swagger-api https://github.com/swagger-api Besides, it would be awesome if browser plugins could make SQRL available for sites that don't support SQRL yet. 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.

ConfucianNardin 9y ago

Note: This was first published in 2013 (or maybe even earlier). It hasn't gained traction since, so it seems unlikely it ever will.

jelv 9y ago
The development started in 2013, but it's, at this moment, not finished. Steve Gibson commented that it's almost complete and is just working on the documentation. So it's not that weird that it's not adopted in mainstream sites.
- borplk 9y ago
  I'm a fan of it but I doubt it will gain traction just because it's a little unfriendly for businesses dealing with average Joes who can't be trusted to take full responsibility.
- wscott 9y ago
  Steve is writing an official reference implementation for Windows. He is trying to get everything right and updates the spec with what he learns. I believe there are other unofficial implementations currently.
- torgoguys 9y ago
  Just commenting on timing here, not the pros/cons of SQRL, which is a whole other discussion: It's been "almost done" for a long time now. At Gibson's 2014 digicert presentation, he said he would be able to demo it in about a week. Nope, that initial demo didn't happen for another 6 months, IIRC. Shortly after that demo--we're talking June 2015--the Windows client was (checking transcript) "almost finished." Today is exactly TWO YEARS TO-THE-DAY later, and I don't think the client is yet complete. I'm all for doing something right, and that's his stated reason for why it's taking so long, but it also means that based on past history, you should take his time estimates with a HUGE grain of salt. He's slow--it has been nearly 200 weeks of time where he claims he has been working on this more-or-less "non-stop" and that it has been his "focus."
  - 9y ago

homakov 9y ago

Check this out - it actually has implementations - https://securelogin.pw/ https://securelogin.pw/

HurrdurrHodor 9y ago

A more viable competitor: https://www.n-auth.com/ https://www.n-auth.com/

cm2187 9y ago
But this is a commercial solution. SQRL is an open source / free protocol.

daveio 9y ago

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. http://attrition.org/errata/charlatan/steve_gibson/ http://attrition.org/errata/charlatan/steve_gibson/

cm2187 9y ago
You can question the implementation. But I think the underlying idea is sound. And it shouldn't matter who introduces the idea.
towerbabbel 9y ago
It seems to be one of the immutable laws of the internet that whenever there is a discussion of anything related to Steve Gibson someone will invariably post the link to that attrition.org site. If I may disregard the entire Ad hominem part and instead focus on the people posting the link. I must wonder how many have actually read what the site says about Steve Gibson and given some thought to what it might mean. It records a dozen or so issues over a the last 17 years. He has been doing the Security Now podcast since summer of 2005. That is a two hour podcast, 50 episodes a year for twelve year. That is 1200 hours of content. That is like 40 books worth. Then there is also the columns he has written and so on. 40 books attempting to explain security issues to a wider audience with only a dozen errors seems an amazingly low error rate to me. If you also look at what sort of errors are reported you see that some of them seem to be more the errors of degree, rather than kind. He seems to have a tendency to blow things out of proportion; for hyperbole. But if hyperbole is such a deadly sin, why is their go to reference for Steve Gibson errors The Register?!? Now I'm sure Steve Gibson has made more mistakes than those, and the he holds silly opinions on some things. Everyone does. But that attrition.org page does not seem to convince me of anything aside from making me lower my esteem for the attrition.org site. I do wish that rather than this sort utterly lame Ad hominem attacks proposals were judged on their own merit, but this is the internet, so maybe I shouldn't hope for too much.
- borplk 9y ago
  I wrote an almost identical comment to yours last time there was some discussion about SQRL and Steve and someone mentioned the same thing (your comment is more complete). I think people have just bookmarked that page and copy-paste it as soon as someone mentions him. Let it go people. He and Leo have done a wonderful service with Security Now for the community for more than a decade. The quality of his content is better than what you can find in many universities and it's available to everyone for free. Can we have any of you go on public record every week for 12 years and see how you do? Really unnecessary and undeserved personal attacks ... gets old.

rs232 9y ago

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. https://secure.skandiabanken.no/Authentication/QRCode https://secure.skandiabanken.no/Authentication/QRCode

kennydude 9y ago
Sounds a lot better than UK banks with their stupid "enter the third, fifth and seventh characters of your password" which is frustrating
- mbreese 9y ago
  It also makes you wonder how they know what the third, fifth, or seventh characters of your password are... I suppose they could create multiple hashes each time you change your password, but I'm not optimistic.
  - kennydude 9y ago
    It's more than likely plaintext or "encrypted" (and decrypted to check if it's correct)
  - LiquidFlux 9y ago
    I suspect it may be more related to being keylogged or an equivalent, and not revealing your entire password in the process.
  - arethuza 9y ago
    My UK bank requires a password and a separate secret phrase that they do the letter selection from. You need to supply the password and 3 letters from your secret phrase. As my phrase is quite long I pretty much always end up writing it down or using an editor.... :-)
    - 9y ago

eugene_pirogov 9y ago

This is actually implemented in the biggest bank of Ukraine, PrivatBank. 1. Open login page https://www.privat24.ua https://www.privat24.ua on the computer, you'll see a QR code, 2. Take your phone, open bank's official Privat24 app, 3. Within the app select "Scan QR code", 4. Upon scanning, the page on the computer is reloaded and you are presented with the dashboard. 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).

wink 9y ago
Sounds awesome, whereas my German bank still doesn't allow proper passwords, only "PINs" no longer than 5 characters. Fun fact, you can change your login though, it can be 15 characters including non-alphanumeric. /s
- elcapitan 9y ago
  Which German bank is that?
  - cygned 9y ago
    I know about one. Three other banks where I have accounts, users are allowed to use passwords with a maximum length of 16 characters, which are also restricted in the way that you cannot choose freely. Things like & or { are usually forbidden.
  - wink 9y ago
    Stadtsparkasse München - and I'm not sure if the other Sparkassen are better. Maybe some are, you never know what exactly they share and what's different.
simooooo 9y ago
WhatsApp does this too but I don't think its the same as SQRL, as it is a 3rd party doing the work.
deleted 9y ago

sametmax 9y ago

But if somebody steals your unlocked phone the person can connect to your bank ?

vim_wannabe 9y ago
I'm guessing it depends on the client. Most security oriented software on iPhone at least ask for unlock code or Touch ID when opening the app.
- falcolas 9y ago
  You typically have to set a security code first, before those can be requested. My memory of setting up a new phone is rusty, but I don't recall this being a required step.
ipottinger 9y ago
As an aside, please note that the use of a phone and the scanning of a QR code when using SQRL has been more recently relegated to an edge case. The vast majority of users will never do so. SQRL has its own sqrl:// schema.

Numberwang 9y ago

For those in Sweden(and maybe elsewhere), is this similar in any way to the method BankID uses?

theninth 9y ago
By BankID I think you are referring to "mobilt BankId"? They are both providing 2FA, but that is where the similarities end. They solves completely different problems. If you use an e-mail-adress (and a password of course) to login on multiple sites, anyone with access to those sites databases could check which services you uses and they could collect all data from all of those databases to get alot of information about you. Mobilt BankId is like that but worse from a privacy perspective. It make sites (I think, someone correct me if I'm wrong) able get, not only the information you provided, but also tie that to your real life identity. That's great for Skatteverket and Försäkringskassan, but for "Random Hacker Forum", it might not be that great. SQRL will not in itself reveal anything about your identity. Even if you use SQRL to login in on different sites and someone had access to all of those sites databases they would not be able to see that you use the same SQRL-identity to login. Also, BankID is relying on a third party for authentication where SQRL is not.

khana 9y ago

I'm all in. I listen to SG's podcast and he is excellent and knows computers at an assembly level.

midnitewarrior 9y ago

This was posted about 4 years ago, and it was half baked and fully attacked by wherever I saw it posted. 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.

s_tec 9y ago

Aside from a few cryptographic details (like which elliptic curve to use), this system is identical to [BitId](https://github.com/bitid/bitid https://github.com/bitid/bitid). BitID is already being deployed in the Bitcoin ecosystem. For instance, you can see it on the buy/sell service [Glidera](https://www.glidera.io/loginbitidqr https://www.glidera.io/loginbitidqr). 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.

Veratyr 9y ago

Something that I haven't seen mentioned yet is that systems similar to this are already pervasive on the Chinese internet. Here's Taobao's login page: https://world.taobao.com/markets/all/login https://world.taobao.com/markets/all/login And Alipay's: https://login.aliexpress.com/ https://login.aliexpress.com/ 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.

md_ 9y ago
Flipboard also uses QRs. But to be accurate, this is a convenience feature, not a security feature. It's still phishable.
zxcvbn4038 9y ago
Very cool, but it looks like everybody is doing their own thing, no interoperability. =(

md_ 9y ago

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 http://www.zdnet.com/article/open-sesame-googles-no-password-log-in/ http://www.zdnet.com/article/open-sesame-googles-no-password.... 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. 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. 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. 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. 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.

ramriot 9y ago

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. 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. As to the second, SQRL is not a 2FA succinctly it is a:- Single factor (1FA), 2-party, Zero knowledge, pseudonymous proof of identity. 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. 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. 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. 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. 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.

davidkhess 9y ago

To me, the fatal flaw in SQRL (and options like it) has been MITM (man in the middle) attacks. For instance: https://security.stackexchange.com/a/46205 https://security.stackexchange.com/a/46205

ramriot 9y ago
Which would make it no worse in that respect than anything else & in many respects much better, please Note: https://news.ycombinator.com/item?id=14472929 https://news.ycombinator.com/item?id=14472929 The use of remote QR-Code authentication is no longer a key feature here, the expectation is that it will almost never be used unless for exceptional circumstances.
- davidkhess 9y ago
  Can you expand on what "Client Provided Session" means?
  - ramriot 9y ago
    Very simply: In the browser session authentication use case, as well as a sqrl:// scheme link being launched the browser makes a parallel internal probe and then direct GET request to http://127.0.0.1 http://127.0.0.1 on port 25519 which is locked by the local client the payload of the original link base64URL is encoded in the url, which hands over control of what follows to the client application. The client performs authentication as normal, but instead of the session being updated via a browser push a redirection response is returned to it via the client which leads to a single use very temporary and unguessable link that kicks off the authenticated session. Because of browsers same origin policies and other security protections we believe it is not possible for an MITM attacker actively tunneling a valid SQRL login page to gain access to this information. Clearly this does rely on the browser agent upholding strict security policies, but then if it did not you would have much bigger problems.
    - davidkhess 9y ago

oliver2213 9y ago

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