SQRL – Secure Quick Reliable Login
grc.com
grc.com
- 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.
HMAC(Master key + Domain) -> private key + identity (public key)
HMAC(Master key + Domain) + challenge -> response
1. first factor
2. HMAC(Master key + Domain) + challenge -> response
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.
The way it deals with compromised private keys is that you can store the list of websites you authenticated to on a central location and run a reset of all your authentications on all websites in one go from there. But then it relies on a third party.
I don't pretend that this is the ultimate solution (nor am I aware that there is an ultimate solution) but it does seem more secure and practical than anything else I have seen so far. I am sure you can make more secure but less practical and of course less secure and more practical.
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.
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.
> How SQRL changes things
> When using SQRL, users do not identify and authenticate themselves with a username and password. Instead, their unique user identity is derived from their secret master key and the website's full domain name.
So that's similar to what U2F does - domain name (origin) is part of the protocol.
However, the limitation are there, FIDO goes further.
SQRL is much simpler and doesn't have that.
Let's say you are a bank, you want to use U2F or UAF. Some cheap 5$ U2F stick is not acceptable, you want to require some high quality stick from trustworthy people. Or maybe you even want to give your costumers costume sticks.
In UAF its even more important. You want to be able to reliable exclude Finger Print sensors or something like that.
It adds security and options. As long as the certification is not highly restricted I don't see it as a problem.
As a vendor - oh, yes, of course, I would absolutely enjoy as much control as possible.
As an end-user - nope, I want to decide on my trust vectors on my own. Even if I'm utterly delusional about my abilities to do so.
I just believe that a freedom to make a decision - even a terribly wrong one - is better than a secure lack of any. I don't want "trusted" authentication tokens to access sites from a "trusted" browser on a "trusted" OS to be displayed on a "trusted" monitor and so on[1]. Even if that makes world much more secure place.
________
[1] Yes, that sounds far-fetched and alarmist, but it's really all the same - end user is out of control and "their" hardware is attested for the sake of security. We're already knee-deep in there, please don't let it spread on more things, gradually gaining acceptance.
The good thing is that while a bank can force you to use some specific device, they can not stop you from using that same device in other places.
Here, banks used to implement proprietary measures. ActiveX or Java applets, custom encrypting HTTP proxies, nonsensical password policies and all other sorts of weirdness you can imagine. It's still not unheard of (because those institutions are extremely inert), but I'm absolutely sure the norm is shifting. Saner stuff gets adopted.
And until they don't - YMMV, but that's okay with me. Personally, I'm better with them lagging behind, rather than leading us to the "trusted" computing future. Security is important and nice, but not when it has adverse side effects.
It might help the google, microsoft and bank of america of this world. But these are not the ones leaking our credentials (most often). It is the smaller websites who will not have the resources to go through some certifications or implement these protocols from scratch.
What is really missing is a common, free standard protocol, that can be easily adopted by a small website.
Is Fido trying to answer this use case?
See this example Java library: https://github.com/Yubico/java-u2flib-server
But in general they seem to be doing a very good job of forcing hardware to be standards complaint. They are putting quite a bit of effort into standards testing suites that you can use to validate your code as well.
A good thing about it is that on the server it only saves site-specific public keys, so small websites that get hacked leak important information.
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.
Second, U2F is not about USB sticks only. It is a protocol that works over NFC or Bluetooth. Soon it will also be possible to use your phone as a U2F authenticator for your laptop.
Third, how is it not adoption when Facebook, Github, Dropbox, Google and many others have added it.
Forth, a lot of hardware already has support built in. Lenovo laptops, Samsung phones and so on. Android has added an API. The new Snapdragon chips have it implemented on a very low level that will allow key storage in a secure enclave with dedicated transport to the finger print reader for example.
Five, where are you getting this 19$? You can get sticks for as low as 5$.
When is the last time authentication technology has been adopted like that? I would think never.
Google has published a paper about their experience, https://www.yubico.com/2016/02/use-of-fido-u2f-security-keys...
adding != users are using it (they don't)
19 is price for yubikey, maybe some do for 5, it doesn't matter because it should be 0 and no hardware costs that. Making auth layer for general public as hardware is a mistake #1.
>When is the last time authentication technology has been adopted like that? I would think never.
Facebook Connect. Hell of a success. It's centralized, though (and we made decentralized securelogin.pw)
Google says some of their 50k employers are happy with experience. That's it, has nothing to do with users of Google.
I use it. My company uses it for Google GSuite (mandatory). I know many people who use it.
Also, this is pretty new stuff, of course its not used by everybody yet. The Spec has not been finalized for very long. U2F has actually shown very good growth. It has been adopted in some mainstream browsers and Firefox will have it soon as well.
Adding a completely new authentication layer to the hole web is a monster task. No solution will solve all problems in a couple years only.
> 19 is price for yubikey, maybe some do for 5, it doesn't matter because it should be 0 and no hardware costs that. Making auth layer for general public as hardware is a mistake #1.
Again, much future hardware will just have it built in. You have a smartphone anyway, why not use it as a second factor? Your wearable could be your U2F device. That's also U2F. U2F is a protocol, not a hardware stick.
Also, you don't need hardware. You can use software implementations if the server allows that.
> Facebook Connect.
That's federation layer and you can use U2F to make it saver for you.
Once this is established the hope to push the envelope further with future versions.
That's the reason this stuff gets adopted. Everybody understand that these issues still exist. Nobody believes that FIDO 1.0 is the solution for all problems that exist in auth.
I for one much rather buy two U2F sticks, then entering that stupid TOTP token one more time.
Currently people use passwords then add TOTP to increase security.
FIDO wants to improve the situation so they introduce UAF to replace passwords, and they replace U2F to replace TOPT.
What exactly is your problem? They did exactly what you wanted, they invented UAF to improve on the first factor. For high security application you can add a second factor. Are you arguing there is never a case for a second factor?
I really don't understand your issues.
Oh, how is it going? Is there any UAF supporting app, ie no passwords? All I see is slides and presentations.
> Are you arguing there is never a case for a second factor
Correct, once first layer is fixed and password-related attacks are mitigated, there's no need for u2f as it doesn't stop malware.
Even something as basic as hmac(masterpw, domain)-app would do better job than FIDO stuff altogether.
You can verify PayPal transaction right now with UAF. Not exactly a small fish.
UAF does not jet have much browser support yet, everybody is waiting for Web Authentication API that is in standardization right now.
> Correct, once first layer is fixed and password-related attacks are mitigated, there's no need for u2f as it doesn't stop malware.
That's just stupid. If you use a finger print sensor as a convenient first factor then you might as well still want a second factor.
The idea that there is never a use for a second factor is just total nonsense.
> Even something as basic as hmac(masterpw, domain)-app would do better job than FIDO stuff altogether.
The security of that would be far, far worse. Not to mention tons of other practical problem with that idea.
You keep talking about factors, which is just a word, not a technical term. I repeat: you do not need u2f with fixed first layer. No plausible threat model. Malware attack gets delayed, not prevented. If you decide to reply please define word "factor".
U2F is designed to add additional security by you having to prove that you physically own something.
> you do not need u2f with fixed first layer
Again, that why there is UAF, it has nothing directly to do with U2F. In UAF you have to somehow (bio or knowledge) prove that you are who you are.
In high security application you might want to both have local authentication (UAF) and additionally prove of possession (U2F).
> Malware attack gets delayed, not prevented.
Of course it helps. If you use your laptops fingerprint reader as a first factor, somebody steals your laptop, gets the fingerprints from it, he will still not be able to access your online accounts because they need U2F.
If its a website that uses password and you get phished this will be completely useless if they don't have access to your U2F authenticater.
So we are left with attacks that control your computer once you unlock it. Malware. And with malware we can exploit your computer right now (no "second factor") or few days later (wait for you pressing that USB button). My point being these both cases are giving same security, but second one is much worse usability.
>If its a website that uses password and you get phished this will be completely useless if they don't have access to your U2F authenticater.
Pre-condition to this discussion is that "first factor" is not a password but some kind of client certificate, i.e. phishing and reuse is not in question. Then we are looking at what U2F offers us: horrible user experience with most browsers+devices not supporting it for the sake of just delayed exploitation? Thanks, no.
I do wish more sites allowed TOTP (Google Auth) because it works well and avoids the third party dependency, but I'd be happiest if sites would just stopped disabling paste so I can use strong passwords with my password manager. (Synchrony Bank, I'm looking at you and all your dozens of co-branded web sites)
No reason not to just revoke the old factor and buy a new one.
Even multiple tokens isn't a good solution for lots of services, since you need possession of the token to enroll.
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..?
https://securelogin.pw as another user suggested might be a better alternative, then.
Too bad, I really liked the name.
1. Open login page 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).
Fun fact, you can change your login though, it can be 15 characters including non-alphanumeric. /s
but I'm like 99% sure it's a proprietary protocol, not SQRL
I suppose they could create multiple hashes each time you change your password, but I'm not optimistic.
As my phrase is quite long I pretty much always end up writing it down or using an editor.... :-)
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.
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.
Here's Taobao's login page: https://world.taobao.com/markets/all/login
And Alipay's: 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.
I am looking for a webpage like this: http://swagger.io/ And this: 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.
1. User reaches login page
~~~ attacker MITMs the nonce (the hard part) ~~~
2. Scan QR, validate that nonce with a POST from the app.
It's now in the cache waiting for the login page to follow through.
~~~ attacker hits login button with the same nonce ~~~
3. User hits the login button, and depending on implementation, is either
denied access as nonce has been deleted from the cache, or logs in and
doesn't notice the attacker at all.
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.
But this is no different from any other password manager. Once you have the master password, you can access everything else.
The difference in my opinion is that because you would only leave this master key on one device, preferably a hardware protected, encrypted device like an iphone, stealing this key is significantly difficult. Whereas with a password manager, you have to type your credentials on a machine open to malware and key loggers.
I made 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.
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.
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.
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 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.
If it does require native browser support, I would worry about chicken and egg adoption issues.
Provided that is the attacker is not using same domain origin, scheme, port etc. Which if they were you would perhaps have greater problems.
That said, we will all be testing that feature most thoroughly.
I think the only way this could work is if you set the window.location to localhost:25519 when starting the SQRL authentication. That will result in harder UX problems to solve but it does seem feasible.
Regardless, having reviewed FIDO and the W3C Web Authentication API, it seems to me that SQRL doesn't have a chance of seeing any wide adoption once those two are available. They have the dual advantage of standardization and platform control that are nearly impossible to overcome by external offerings.
How will it work on mobile only world? Can this also work on iOS and Chrome OS?
Can 1Password implement SQRL?
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.
It hasn't gained traction since, so it seems unlikely it ever will.
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."
Do have a look at https://medium.com/@shardul.citrus/passwords-bad-ux-security...
P.s. I work for AuthMe.
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.
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.
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.
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.
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.
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.
https://www.grc.com/ssl/ev.htm
Which has the basic premise of "if you run a device completely controlled by your company, somehow Firefox will magically have special code integrity that IE doesn't".
So your company can make any site show the green ev bar in IE.
This cannot be done in any other browser so in firefox, chrome and everyone else a green bar means a valid ev cert from a real certificate autority.
On the other hand in IE a green bar does not mean anything because group policy can make any cert show as ev with green bar and all.