4 ms·

Why is SQRL [1] not more popular? [1] https://www.grc.com/sqrl/sqrl.htm https://www.grc.com/sqrl/sqrl.htm

cm2187 8y ago
Reference source in assembly, sponsor not particularly popular or known in the silicon valley. It's a pity because I think the concept is really smart and practical. I would not run it on a windows machine though.
- mtgx 8y ago
  I assume it could be implemented on a secure USB stick for key storage, too.
  - botto 8y ago
    I think Steve mentioned Yubikey was looking at implementing SQRL once it was complete
- groovybits 8y ago
  Not sure about Silicon Valley, but Steve Gibson is well known in the security community. He has been working on this for years now, and has had beta testers for the past year I believe. SQRL (as a whole deliverable package) is not finished yet though.
tialaramex 8y ago
It ends up with the same gap as the TOTP approaches. The user is _supposed_ to verify that this is goodguy.example, their bank's site. But they don't. Humans are very, very bad at spotting that a routine course of events didn't happen. If the human doesn't do this apparently pointless busywork, their security is secretly destroyed. If you ignore the fact that the SQRL says "goodguy.example" but the phishing site you're on says "badguy.example" then you authorise the bad guys to log into your bank account. Oops. In WebAuthn and U2F this doesn't work because the web browser was brought in to the party. "This" says the browser, "is badguy.example", and the user isn't asked to do any busywork with a risk of getting themselves in trouble. The bad guys get nowhere. Railway example: Train drivers do the same routes over, and over, and over. They get used to things that they know intellectually are just patterns, routines, not set down anywhere as facts. Hypothetical example: maybe at Oakwood junction on the Down Fast with the Express you always get a Caution, never Clear or Danger, if you're on time, because the signaller is moving a local out of your way ahead. Without any computer assistance, drivers, despite being trained about this specific problem, will look at a signal showing Danger at Oakwood junction on the Down Fast, and their brain says "No, this is always Caution" and _even though they saw a Danger signal_ and even though they are trained that if they aren't sure they must treat signals as "Danger" - they act as though it was definitely Caution. With a computer helping, the driver can be "shaken" out of this mistake, for example the computer can sound an audible alarm that the train seems not to be slowing appropriately, and then since this alarm doesn't normally sound, the driver may go "Wait, was that Caution? Actually I think it was Danger! Oops" and brake. But we must be cautious with such aids, most of the British railways have a system that sounds a horn each time you're shown a signal that is NOT Clear. The driver acknowledges the horn, or if they do not the train autonomously brakes to a halt. But both "Caution" and "Danger" are not Clear, at our hypothetical Oakwood junction the driver would get used to hearing the horn, because the signal says "Caution", except today it is "Danger" ...
- botto 8y ago
  I mean SQRL does help with the fact that if you scan the login of a bad site that is portraying as a good guy then you log in with different credentials as the site url is embedded in the QR login image. If your talking about iframing goodguys website inside of badguy website, then yes this is an issue that goodguy should not allow iframing of their login page.
  - tialaramex 8y ago
    No, the scenario goes like this: 1. You, the victim, go to badguy.example, perhaps as a result of a phishing email, a sponsored link, or it's a typo squatter. 2. badguy.example tells you it's Good Guys. You need to log in (as is usual with Good Guys) so you go to the login screen... 3. When you do this the Bad Guys connect to goodguy.example and ask to log in too, they get a SQRL code for goodguy.example 4. Bad Guys (still pretending to be Good Guys) show you the SQRL code to log in to goodguy.example 5. You scan the SQRL code and press OK 6a. Now the Bad Guys are successfully logged in as you since this was their SQRL code for your account. 6b. You receive some error message or other stalling tactics to buy them some time. The SQRL user has been taught, over, and over, and over, that they need to check the domain name shown in SQRL. They did, it said goodguy.example, as they expected. Unfortunately that was worthless because what mattered is that they were visiting badguy.example in their web browser. Gibson is aware _this_ can only be fixed the way U2F/ WebAuthn fixed it, which is to modify the user's web browser, not just add a fun phone app. And once you've done that modification (Firefox, Chrome, Edge in beta, Safari to come) the QR code and phone app plays no useful role. It's a hangover from Gibson's original idea that doesn't quite make any sense once you fix the actual problem.
    - criddell 8y ago
      I was just reading about this problem here: https://www.grc.com/sqrl/phishing.htm https://www.grc.com/sqrl/phishing.htm Gibson give a pretty honest assessment of the problem and what the weaknesses are under the various configurations. When the login agent is on the same machine as the browser (which would be the normal case), the problem mostly goes away (if I understand it correctly).
groovybits 8y ago
SQRL is not finished yet. Steve has said he will do an SN episode on it when its finished, soon(tm).

Reference source in assembly, sponsor not particularly popular or known in the silicon valley. It's a pity because I think the concept is really smart and practical. I would not run it on a windows machine though.

mtgx 8y ago
I assume it could be implemented on a secure USB stick for key storage, too.
- botto 8y ago
  I think Steve mentioned Yubikey was looking at implementing SQRL once it was complete
groovybits 8y ago
Not sure about Silicon Valley, but Steve Gibson is well known in the security community. He has been working on this for years now, and has had beta testers for the past year I believe. SQRL (as a whole deliverable package) is not finished yet though.

tialaramex 8y ago

It ends up with the same gap as the TOTP approaches. The user is _supposed_ to verify that this is goodguy.example, their bank's site. But they don't. Humans are very, very bad at spotting that a routine course of events didn't happen. If the human doesn't do this apparently pointless busywork, their security is secretly destroyed. If you ignore the fact that the SQRL says "goodguy.example" but the phishing site you're on says "badguy.example" then you authorise the bad guys to log into your bank account. Oops. In WebAuthn and U2F this doesn't work because the web browser was brought in to the party. "This" says the browser, "is badguy.example", and the user isn't asked to do any busywork with a risk of getting themselves in trouble. The bad guys get nowhere. Railway example: Train drivers do the same routes over, and over, and over. They get used to things that they know intellectually are just patterns, routines, not set down anywhere as facts. Hypothetical example: maybe at Oakwood junction on the Down Fast with the Express you always get a Caution, never Clear or Danger, if you're on time, because the signaller is moving a local out of your way ahead. Without any computer assistance, drivers, despite being trained about this specific problem, will look at a signal showing Danger at Oakwood junction on the Down Fast, and their brain says "No, this is always Caution" and _even though they saw a Danger signal_ and even though they are trained that if they aren't sure they must treat signals as "Danger" - they act as though it was definitely Caution. With a computer helping, the driver can be "shaken" out of this mistake, for example the computer can sound an audible alarm that the train seems not to be slowing appropriately, and then since this alarm doesn't normally sound, the driver may go "Wait, was that Caution? Actually I think it was Danger! Oops" and brake. But we must be cautious with such aids, most of the British railways have a system that sounds a horn each time you're shown a signal that is NOT Clear. The driver acknowledges the horn, or if they do not the train autonomously brakes to a halt. But both "Caution" and "Danger" are not Clear, at our hypothetical Oakwood junction the driver would get used to hearing the horn, because the signal says "Caution", except today it is "Danger" ...

botto 8y ago
I mean SQRL does help with the fact that if you scan the login of a bad site that is portraying as a good guy then you log in with different credentials as the site url is embedded in the QR login image. If your talking about iframing goodguys website inside of badguy website, then yes this is an issue that goodguy should not allow iframing of their login page.
- tialaramex 8y ago
  No, the scenario goes like this: 1. You, the victim, go to badguy.example, perhaps as a result of a phishing email, a sponsored link, or it's a typo squatter. 2. badguy.example tells you it's Good Guys. You need to log in (as is usual with Good Guys) so you go to the login screen... 3. When you do this the Bad Guys connect to goodguy.example and ask to log in too, they get a SQRL code for goodguy.example 4. Bad Guys (still pretending to be Good Guys) show you the SQRL code to log in to goodguy.example 5. You scan the SQRL code and press OK 6a. Now the Bad Guys are successfully logged in as you since this was their SQRL code for your account. 6b. You receive some error message or other stalling tactics to buy them some time. The SQRL user has been taught, over, and over, and over, that they need to check the domain name shown in SQRL. They did, it said goodguy.example, as they expected. Unfortunately that was worthless because what mattered is that they were visiting badguy.example in their web browser. Gibson is aware _this_ can only be fixed the way U2F/ WebAuthn fixed it, which is to modify the user's web browser, not just add a fun phone app. And once you've done that modification (Firefox, Chrome, Edge in beta, Safari to come) the QR code and phone app plays no useful role. It's a hangover from Gibson's original idea that doesn't quite make any sense once you fix the actual problem.
  - criddell 8y ago
    I was just reading about this problem here: https://www.grc.com/sqrl/phishing.htm https://www.grc.com/sqrl/phishing.htm Gibson give a pretty honest assessment of the problem and what the weaknesses are under the various configurations. When the login agent is on the same machine as the browser (which would be the normal case), the problem mostly goes away (if I understand it correctly).

groovybits 8y ago

SQRL is not finished yet. Steve has said he will do an SN episode on it when its finished, soon(tm).