If you haven't heard of it, I highly recommend checking out SQRL (secure quick reliable logon). It solves the problems of Identity on the internet in a nice, convenient, and decentralized way. While it isn't going to be widely adopted for a while, we should be talking about it anytime we see trackers in password management apps or breaches of websites.
This looks very interesting. Are there any websites or services actually using this?
The problem with the solution chosen here is that this requires yet another app for authentication and yet another account for synchronisation of credentials. If this were to be built into browsers, it might replace traditional passwords in time.
How does SQRL work when it comes to apps? Does the Android app natively support other applications calling it to authenticate? What about authenticating devices that can't run the client application (smart TVs, for example), can they still access the accounts authenticated by SQRL?
Right now, SQRL seems to be competing with Webauthn, which has been built into browsers already, but does so through an external daemon running alongside the browser. I'm not optimistic about its chances here, to be honest.
I just realized my first reply did very little to answer your questions, so I'll take a look at them one by one here:
> Are there any websites or services actually using this?
To my knowledge, there are not many (if any, besides the SQRL forums) working, live implementations out there. I played around with it and got it working on a couple of hobby projects over a weekend and it showed a lot of promise.
> The problem with the solution chosen here is that this requires yet another app for authentication and yet another account for synchronisation of credentials. If this were to be built into browsers, it might replace traditional passwords in time.
This is very true, but I believe SQRL as an open protocol will have long tail legs over time.
> How does SQRL work when it comes to apps? Does the Android app natively support other applications calling it to authenticate? What about authenticating devices that can't run the client application (smart TVs, for example), can they still access the accounts authenticated by SQRL?
At its core, SQRL is essentially a Challenge/Response mechanism. It would be possible for a device connected to a TV present a QR Code and have its session be authenticated by a device using the out of band HTTP request from the SQRL client scanning the QR Code (there are problems with this, like forwarding the QR code via a MITM attack to gain an authenticated session, however, the attacker only has a single logged in session instead of having access to a password that now needs to be changed, and any problems related to this MITM attack would also affect other user credentials like the email and password).
> Right now, SQRL seems to be competing with Webauthn, which has been built into browsers already, but does so through an external daemon running alongside the browser. I'm not optimistic about its chances here, to be honest.
Short term, I agree with this. However, long term I think WebAuthN is going to suffer from other problems which do not affect SQRL (user adoption of 2FA keys and user inconvenience in managing those 2FA items) SQRL provides some really nifty ways to transfer an identity safely to a host of other devices as well as rekeying an identity with the rescue code in the event an identity is compromised. It also doesn't require the management of those devices on any third party site.
The four PDFs present on the SQRL page to a better job explaining than I will here, however I'll summarize a bit:
The SQRL client registers the sqrl:// prefix to pass the login challenge to the SQRL client. The client, after a password or the pin (depending on if the password is present in RAM) is entered, responds to the server using signed credentials which are only valid for the domain being authenticated. That challenge creates a logged in session for the user and redirects back to the website.
There is also a QR code method of logging in, which depends on the user to confirm the domain name of the site being logged into. This is admittedly less secure, however, does provide some handy convenience when on an untrusted system by not requiring a user to give up their password. There are attacks that can be used to gain a session, however, these are thwarted when the on device authentication path is used (which requires some software to be installed on the users device)
This is interesting stuff, but as others have said they do a really bad job of presenting the what it does and how it fits it.
Having now read a lot of their docs, they don't seem to acknowledge basic things at all.
For one, the identity string it generates for a site is static, and is the only thing need to identify/log you in. They never cover that this basically _IS_ a password. If you have a this static string, you have the password for that site.
Further it sounds like the website operators also need to store these strings as plain text. I don't know how their rekeying method would work other wise.
This means to me that if a websites database is stolen, then a person with that database could impersonate everyone immediately! No need to get a password cracker out at all.
A website operator would need to completely disable all the existing keys, requiring everyone to rekey.
They have a global rekey method, but all their single site methods documented are very very manual and only possible if the site accepted you're old key.
The global rekey method is also very scary to me. You need to visit a site for the rekey to happen. They state that after a rekey it will send your current and old key over. However how many keys will it send? What happens if I have to they N times because of different site data beaches. Will sites I haven't visited no longer be usable because their key is no longer available?
All of these points have inaccuracies, and I'll run through them one by one:
> For one, the identity string it generates for a site is static, and is the only thing need to identify/log you in. They never cover that this basically _IS_ a password. If you have a this static string, you have the password for that site.
The identity generated is a public key based on a private key in the identity. You do need one password, the master password for the identity on the device for an initial decryption to make the Challenge Response work.
> Further it sounds like the website operators also need to store these strings as plain text. I don't know how their rekeying method would work other wise.
What the website stores is a public key. Rekeying works via some other cryptographic methods to create new public keys. A server, presented with a previous public key and a new public key will replace the previous key with the new key. The new key can be confirmed as belonging to the previous identity, while not able to be regenerated by the identity without the rescue code. Full disclosure: Didn't really understand the math behind it, but that's the premise of the protocol. Securing that rescue code is extremely important and it should be stored separately from the identity (think at home with you birth certificate in the event your device is stolen while you are somewhere else).
> This means to me that if a websites database is stolen, then a person with that database could impersonate everyone immediately! No need to get a password cracker out at all.
The database only contains public keys of the user for the purpose of authentication. This table could theoretically be published, the compromise of the key does not compromise the identity nor allow a thief to log on (it would obviously not protect other information tied to the user like the email, address, etc. However, its a step in the right direction because it isn't a hash of a password to be rainbow tabled or the like).
> A website operator would need to completely disable all the existing keys, requiring everyone to rekey.
The compromise of all keys in the db would not compromise any identities. If a malicious actor changed identities to their identity, then there would definitely be problem, however, the operator could restore the public keys from backup and keep moving. This is not much different from passwords today, except that the user could no longer trust the password, no trust is lost in the public key.
> They have a global rekey method, but all their single site methods documented are very very manual and only possible if the site accepted you're old key.
This is valid. I'm imagining a perfect world with a correctly implemented spec. We can all work together to make it a reality.
> The global rekey method is also very scary to me. You need to visit a site for the rekey to happen. They state that after a rekey it will send your current and old key over. However how many keys will it send? What happens if I have to they N times because of different site data beaches. Will sites I haven't visited no longer be usable because their key is no longer available?
It would be semi-true that you would lose access in a world where software is the only intervening factor. The reality here is different: The public identity is string in the DB associated with the user. A website operator can have a user come in with their birth certificate and passport or whatever, verify a user, and change their public key in the database. This would be totally out of scope of the spec, not expected behavior, and potentially compromises perfect security, but the reality we live in is imperfect.
Everything, at some level, is going to come down to trust, and anyone with DB access can do anything anywhere anytime.
EDIT: I reread this again and realize what you are talking about is the string of the public key being stored, and potentially providing an avenue for an attacker to replace that string with their own identity in order to gain authorization of that user. I do think that is a risk, however, an attacker with DB access is probably not going to waste time impersonating users: they have access to the DB directly.
This would only be a problem in the instance a users data is encrypted and can only be decrypted by the user. So logging in as the user would grant some special way of seeing their data (though even here, if the server holds all the secrets, this isn't secure).
SQRL has an answer for this, as a private key can be stored with the SQRL identity to allow data to be accessed by the user who can also prove they have access to the identity. This would allow a server to reliably store sensitive information without worrying if the public key of a user got changed to allow a malicious actor to impersonate said user.
I can only imagine this being leveraged for medical records or financial transactions, but a way is built into the protocol.
I really appreciate your thoughtful and thorough response!
Most of my inaccuracies stem from the fast that I didn't see the challenge response part, it seemed like what the web services received was very static.
Thanks for the pointer, but I'm initially very skeptical. Not to judge a book by it's cover but that website looks like it was made in 1990. They also don't do a very good job explaining what this is. I found this:
It says "Using a SQRL app, a master identity is created and shared among the devices. Websites which support SQRL logon trigger the app to securely identify the user."
How does this happen? How can a website talk to an app?
The first document, SQRL explained, does a decent job describing how the system works. Having to download a PDF to read text on a website isn't the greatest of UX experiences.
The talking to seems to happen through a custom sqrl: URI-scheme. That's something that's supported by most platforms I know of; Steam uses the same mechanism to start installing a game you purchased in the browser, if I remember correctly.
To me, it's much more concerning that they do such a bad job of telling me what SQRL does than the fact that the page looks dated. At least it's clean-looking.
But I clicked around for a while and only found some videos that might show me what SQRL does, but I didn't actually feel like watching a video, so I still don't know.
Based on what I read, it sounds like snake oil so far. Too good to be true. I don't remember the phrase, but it suggested it would be my last password solution ever, which just sounds like snakeoil.
Also, it seems like only the Windows implementation is mature. All other implementations are by third parties and are marked as not being complete.
I would recommend reading through at least the first PDF on the site to get an idea of what it is and how it works. The short version is: It's a replacement password manager-esque protocol that enables logging into a web server while leaving no compromise-able secret in the servers database.
> Some web sites have started to offer support for passwordless authentication using FIDO2 hardware keys. This offers similar security properties to SQRL (in some ways arguably better), while also being very simple to use.
Right.
> A major downside is difficulty of backup. The private keys are locked inside the hardware and cannot be accessed in any way.
That's a feature, not a bug. You buy at least 2 keys (1 backup), ideally 3 (2 backup).
As for SQRL, I never took anything serious at grc.com/Steve Gibson. He was all about snake oil 20 years ago, and probably still is.
Why is this better than WebAuthn? It looks almost the same but WebAuthn has much more support. It can use software-defined keys like Krypton though certainly it would be good for browsers to have standard APIs for this stuff.
The spec was recently completed and there are multiple efforts to bring it into a more well rounded existence. The work is being done by volunteers, so it may take some time to become a reality across the internet, however, the seeds are all there to make it work and with some dedication from volunteers I think it has a bright future as possibly being the preferred password manager in the future. If you browse the SQRL forums, you can get an idea of where all the different efforts are playing out, but there is no real central repo of all SQRL code. https://sqrl.grc.com/
https://www.grc.com/sqrl/sqrl.htm
Disclosure: Started looking at it this weekend after hearing about it for a couple of years and starting to help contribute to various SQRL libs