SQRL – Secure Quick Reliable Login(grc.com)
grc.com
SQRL – Secure Quick Reliable Login
https://www.grc.com/sqrl/sqrl.htm
137 comments
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.
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.
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.
Depends on how you define two factor. To me it is using a different device than the device you authenticate with and unless you compromise that device you cannot authenticate any other way.
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.
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.
2FA requires 2 authentication factors like a password & a token i.e. your PIN and banking card. It doesn't really have anything to do with where you enter those. https://en.wikipedia.org/wiki/Multi-factor_authentication
There are nice ways to store private keys; including BIP39 that creates a 24 word mnemonic phrase that you can write down somewhere. (Not that that's perfect security, but it is nice)
The lost master key problem is addressed here: https://www.grc.com/sqrl/idlock.htm
Nice summary, a couple of minor corrections.
* SQRL is not a 2FA, it's a better 1st factor
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....
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.
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.
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.
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.
Uh excuse me?? SQRL provides excellent anti-phishing protection. There are no reusable credentials across domains, and the domain can be displayed on your authenticator.
https://www.grc.com/sqrl/phishing.htm
https://www.grc.com/sqrl/phishing.htm
Domain displayed is no real protection, actually its weakness is what drives phishing. But the link you provided contains some interesting info:
> 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.
> 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.
Cool, I did not see that.
However, the limitation are there, FIDO goes further.
However, the limitation are there, FIDO goes further.
The bad side of U2F is that it looks like yet another push of treacherous computing acceptance. It has attestation certificates that end-user (both legal and physical token owner) isn't supposed to have any control over.
SQRL is much simpler and doesn't have that.
SQRL is much simpler and doesn't have that.
Seems to me the attestation certificates allow people who want to restrict the type of token to do that in a reliable way.
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.
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.
> You want to be able to reliable exclude
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.
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.
I just don't think banks and so on would adopt the technology otherwise. This system makes it possible to use the same protocol for super high security application where you require a UAF authenticater with its own keyboard and screen. A bank just be hacked because somebody used a sup-par authenticater.
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.
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.
Lagging behind, but I'm sure they will.
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.
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.
I've wondered why Yubico is the only u2f device manufacturer that has released a root certificate which validates the attestation certificates that the keys provide - maybe it is to discourage their use so they can't be locked out reliably?
I am not familiar with Fido but I am looking at their website. It looks like a complex protocol for enterprises. Not some simple library available for many programming language and platforms, which any website can easily implement and add as an alternative or a substitute for login/password.
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?
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?
The protocol is open, so you can create open source lib and server. You do not need to certify the open source libraries. There is already a lot of code out-there. The browser have to implement it as well, chrome does, others should follow soon.
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.
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.
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?
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.
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.
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?
I'm surprised they haven't gained wider adoption, their competitors charge yearly fees for their tokens, and in many cases you become dependent on their infrastructure to use them. U2F is a one time investment as long as the token isn't damaged, and your not beholden to Yubico in the slightest. I've got a box of RSA tokens from former jobs. E*Trade still gives out some token with a LCD display for $20 a year as their sole 2nd factor option.
because selling overpriced plastic sticks is a lucrative business which has nothing to do with security or threat models at all. It's just marketing
First of all, Fido is not just U2F. UAF the more important in the long term.
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...
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...
>Third, how is it not adoption when Facebook, Github, Dropbox, Google and many others have added it.
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.
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.
> adding != users are using it (they don't)
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.
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.
I'd rather recommend people use google auth/facebook connect than go through u2f hassle. It's way too inconvenient and will never go mainstream. Did they figure out usable backups yet? Or they still recommend to just buy another stick?
Just the other day I wrote an Oauth login feature in Go for fun. Facebook banned my account three days later for "suspicious" activity. Twitter banned my account in 48 seconds - I didn't even have a chance to setup an Oauth token. That right there shows the problem with being reliant on a 3rd party for access to your site, what if the 3rd party refuses to work with you? Suddenly your cut off from a percentage of your users. (It wasn't all bad, setting up Amazon login was quick and painless and they didn't ban my account!)
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)
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)
currently, gauth connect is best option for general public. It's a fact, they are popular and have no passwords
Your backups are the generated Authenticator backup codes. Most services give you anywhere between 5 and 10 of these, giving you 5 to 10 chances to log in without your stick. That's plenty of leeway.
No reason not to just revoke the old factor and buy a new one.
No reason not to just revoke the old factor and buy a new one.
The problem with this is the backup codes are different for each service. With one service, I can keep a backup card in my wallet, another in my house, and another at somebody else's house in a different city, giving me very high assurance of availability in the event of token loss or destruction. I can't maintain that level of backup for every service I sign up for.
Even multiple tokens isn't a good solution for lots of services, since you need possession of the token to enroll.
Even multiple tokens isn't a good solution for lots of services, since you need possession of the token to enroll.
Its a point-to-point protocol. Its not a login and recovery flow. Its designed to be integrated in what people are already using as a direct replacement for other 2 factors, so it can be widely adopted instead of forcing everybody to something completely new.
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.
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.
"Factor" is a marketing word. There is security threat model, and there are no "factors". u2f introduces another layer instead of fixing first one. That's why they failed - all we needed is a password replacement, not code generator on top of that.
Ok. So lets explain this ELI5-style.
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.
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.
> so they introduce UAF to replace passwords
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.
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.
Replacing passwords is incredibly difficult. Nobody has done it, many have tried. UAF is already supported in a wide number of hardware and applications.
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 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.
> If you use a finger print sensor as a convenient first factor then you might as well still want a second factor.
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".
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".
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..?
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..?
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
But... I read in the comments that it's from 2013..? It will never be released I guess, then.
https://securelogin.pw as another user suggested might be a better alternative, then.
Too bad, I really liked the name.
https://securelogin.pw as another user suggested might be a better alternative, then.
Too bad, I really liked the name.
It has been in development since 2013, but it still is under active development, and is probably(?) going to be released relatively(?) soon.
This is actually implemented in the biggest bank of Ukraine, PrivatBank.
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).
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).
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
Fun fact, you can change your login though, it can be 15 characters including non-alphanumeric. /s
Which German bank is that?
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.
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.
WhatsApp does this too but I don't think its the same as SQRL, as it is a 3rd party doing the work.
[deleted]
That probably is just an QR-code login, but not the same as SQRL login. In the SQRL standard you also have an solution to revoke your identities for each site/app and recover when your device gets stollen.
Yandex.Key too https://yandex.com/support/passport/authorization/twofa-on.h...
but I'm like 99% sure it's a proprietary protocol, not SQRL
but I'm like 99% sure it's a proprietary protocol, not SQRL
Is there another way to log in? I don't have a smartphone so I would be excluded from that.
The use of a phone and the scanning of a QR code when using SQRL has been recently relegated to an edge case. The vast majority of users will never do so. SQRL has its own sqrl:// schema.
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
That probably is just an second factor QR-code login, but not the same as SQRL login. In the open source SQRL standard you also have an solution to revoke your identities for each site/app and recover when your device gets stollen.
Sounds a lot better than UK banks with their stupid "enter the third, fifth and seventh characters of your password" which is frustrating
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.
I suppose they could create multiple hashes each time you change your password, but I'm not optimistic.
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.... :-)
As my phrase is quite long I pretty much always end up writing it down or using an editor.... :-)
I have a lookup table in 1password as my brain can't work with indexing random strings with numbers in them easily
I suspect it may be more related to being keylogged or an equivalent, and not revealing your entire password in the process.
It's more than likely plaintext or "encrypted" (and decrypted to check if it's correct)
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.
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.
Aside from a few cryptographic details (like which elliptic curve to use), this system is identical to [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).
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.
One benefit of doing this in the context of Bitcoin is that users already have mobile apps that can manage private keys (with backups) and scan QR codes. With Bitcoin, if you lose your keys, you lose money, so there is a tremendous incentive for both users and wallet authors to get this stuff right. Using the same technology for logging in an easy next step.
Something that I haven't seen mentioned yet is that systems similar to this are already pervasive on the Chinese internet.
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.
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.
Very cool, but it looks like everybody is doing their own thing, no interoperability. =(
Flipboard also uses QRs. But to be accurate, this is a convenience feature, not a security feature. It's still phishable.
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 (1), https://sqrl.pl/ (2) and 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/ 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.
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.
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
I guess this kind of technology will pick up once Facebook or Google adopt it (or, more likely, develop their own).
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] the login page URL? If so, do I have to use an intermediary cookie to remember which client I sent a given URL to?
It's definitely not stateless in terms of web sessions. To implement it you'd need a cache of recently-validated nonces, which actually opens up an attack vector as far as I can tell:
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.
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.
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.
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.
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.
Which is why the master key shouldn't reside everywhere.
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.
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.
That's a common criticism of any stateless system, like the Master Password algorithm.
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.
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.
I really like the idea, but the time frame of when the protocol will be "complete" seems (as noted by other commenters here and by the fact that it looks to have been posted in 2013) a bit sketchy.
Still, I'm seriously thinking about making server / client libraries for myself and others so this is less of "Here's this really cool idea and a few sort-of complete implementations", and more "Here's this really cool idea, and here's how you can integrate it into your sites if you want".
Check this out - it actually has implementations - https://securelogin.pw/
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.
Why does this need an app? Looks like it would work just as well with a browser extension reading the QR code.
Actually the QR code is not even needed then. It's just browser-generated ids/keys.
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.
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 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.
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.
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
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
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.
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.
Can you expand on what "Client Provided Session" means?
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 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.
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.
It seems like this would require native browser support because if it were done in Javascript, couldn't the MITM be able to take the redirect response and send it on to their backend?
If it does require native browser support, I would worry about chicken and egg adoption issues.
If it does require native browser support, I would worry about chicken and egg adoption issues.
You may think that, but does not appear to be so. The response is a 302/3 redirect which automatically puts it outside the bailiwick of the attackers scope.
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.
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.
Unless you actually set the address bar (i.e. window.location) to localhost:25519 I don't think this is going to work. I've used ajax with REST APIs that return 302s and you will receive the body of the destination page as the return value to the ajax call. The page in the window (window.location) is not going to change. And this is of course if localhost:25519 returns the proper CORS headers in the first place to allow the ajax GET to even occur.
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.
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.
I'm still digesting the documentation but it looks like it would be susceptible to replay attacks also. But if all the web transactions were happening over TLS with PFS, and everyone is validating certificates, I think that would be good enough.
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?
How will it work on mobile only world? Can this also work on iOS and Chrome OS?
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.
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?
Can 1Password implement SQRL?
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.
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.
[deleted]
Note: This was first published in 2013 (or maybe even earlier).
It hasn't gained traction since, so it seems unlikely it ever will.
It hasn't gained traction since, so it seems unlikely it ever will.
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.
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."
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."
I agree, I've been hearing that this is "done" for years! He's not even supposedly working on his main product "Spinrite" because he working on SQRL.
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.
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.
Does this have the facility to choose an identity when logging in since you may have more than 1 account on a site?
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).
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).
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.
Have a look at 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...
P.s. I work for AuthMe.
Do have a look at https://medium.com/@shardul.citrus/passwords-bad-ux-security...
P.s. I work for AuthMe.
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.
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.
Not to mention authme.io redirects to authme.authme.authme.host. I love it.
That's pretty odd. I struggle to see the point. Certainly didn't help establish trust in the service.
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.
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.
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.
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.
But if somebody steals your unlocked phone the person can connect to your bank ?
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.
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.
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.
[deleted]
For those in Sweden(and maybe elsewhere), is this similar in any way to the method BankID uses?
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.
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.
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/
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.
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.
Dunno, read stuff like this:
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".
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".
What he is referring to is that you can add EV certs to IE via group policies.
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.
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.
And if you're running a device where other people have root, then you probably shouldn't be trusting binaries to display certain colours.
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.
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.
You can question the implementation. But I think the underlying idea is sound. And it shouldn't matter who introduces the idea.
A more viable competitor: https://www.n-auth.com/
But this is a commercial solution. SQRL is an open source / free protocol.
- 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.