3 ms·

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

by 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).

by botto 8y ago

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