4 ms·

SQRL protects against phishing by using the site’s URL to generate a per-site Curve25519 keypair on the fly. Same anti-phishing properties as being discussed h

SQRL protects against phishing by using the site’s URL to generate a per-site Curve25519 keypair on the fly. Same anti-phishing properties as being discussed here. SQRL also has key revocation and rotation, but ultimately places responsibily for keeping backups of revocation codes on paper to the end user. But since you only need to do this once for your SQRL master secret, and not for every damn site, it’s a lot more likely to happen in practice.

tialaramex 8y ago
Nope. SQRL assumes that phishing simply won't work. Users are going to be shown example.com and realise that's not right and abort. That's their "protection". But phishing does work, people have tested. Some users notice the domain name is wrong. Some don't. All press on anyway. Why? Because Humans have a psychological problem that makes them bad at giving up. We need to explicitly train safety critical people to go "Oh, this isn't working. I will now report that I failed" rather than keep trying. In normal people the drive to press on is almost unstoppable. Hence "brick wall UI" design for things like HSTS. If you give humans two options, destroy everything versus admit defeat, they pick destroy everything, every single time. So we changed the UI to not have options. "Defeat" announces the UI. And, defeated, the human gives up and doesn't destroy everything. Hooray.
- tatersolid 8y ago
  SQRL does not give the real identity to a phishing site. Full stop. Now a phishing site can do a fake SQRL login, accepting any credentials. But the client will send a different identity (derived keypair) with no information linking to the real identity, so the phisher will have no information with which to persinalize their fake site. The user might press on anyway and divulge some sensitive data if the fake site is really convincing. But the phisher cannot use any credentials passed to them against the “real” site. WebAuthn does NOT solve this “look-like site exists and accepts any credentials” problem either, nor does any other authentication mechanism. The only protection against against what you describe is preventing registration of look-alike domain names entirely, and ensuring all DNS is secured with DNSsec or TLS. Good luck with that; it’s been tried.

tialaramex 8y ago

Nope. SQRL assumes that phishing simply won't work. Users are going to be shown example.com and realise that's not right and abort. That's their "protection". But phishing does work, people have tested. Some users notice the domain name is wrong. Some don't. All press on anyway. Why? Because Humans have a psychological problem that makes them bad at giving up. We need to explicitly train safety critical people to go "Oh, this isn't working. I will now report that I failed" rather than keep trying. In normal people the drive to press on is almost unstoppable. Hence "brick wall UI" design for things like HSTS. If you give humans two options, destroy everything versus admit defeat, they pick destroy everything, every single time. So we changed the UI to not have options. "Defeat" announces the UI. And, defeated, the human gives up and doesn't destroy everything. Hooray.

tatersolid 8y ago
SQRL does not give the real identity to a phishing site. Full stop. Now a phishing site can do a fake SQRL login, accepting any credentials. But the client will send a different identity (derived keypair) with no information linking to the real identity, so the phisher will have no information with which to persinalize their fake site. The user might press on anyway and divulge some sensitive data if the fake site is really convincing. But the phisher cannot use any credentials passed to them against the “real” site. WebAuthn does NOT solve this “look-like site exists and accepts any credentials” problem either, nor does any other authentication mechanism. The only protection against against what you describe is preventing registration of look-alike domain names entirely, and ensuring all DNS is secured with DNSsec or TLS. Good luck with that; it’s been tried.