141–150 of 154 posts
Earlier quoted context omitted.
What in the spec precludes this from being implemented in software? [edit] Reading more of the spec it definitely seems like they meant for it to be possible to implement this in software. So while a physical FIDO device might be preferable, it shouldn't be necessary.
Where would that software run? In the browser or a separate app?
Earlier quoted context omitted.
What do you mean? https://www.w3.org/TR/webauthn/ includes formal specifications.
Formal as in Formal Mathematics -- a specification with a precise definition that can be verified by a model checker to have the desired safety and, if necessary, liveness guarantees.
Earlier quoted context omitted.
Steve Gibson has been promoting his solution for years but as far as I'm aware security professionals have yet to see it as a serious alternative.
SQRL is a half measure, like SMS-TOTP it barely raises the bar because it doesn't solve a key real problem we actually see happening in the wild and so that would just happen more. If site A is protected by SQRL, and I'm a bad guy, I can just live phish sign-ins for site A using SQRL from my phishing site, site B. The users all believe (as with other phishing attacks) that they're being asked for credentials by a leg…
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.
Earlier quoted context omitted.
SQRL is a half measure, like SMS-TOTP it barely raises the bar because it doesn't solve a key real problem we actually see happening in the wild and so that would just happen more. If site A is protected by SQRL, and I'm a bad guy, I can just live phish sign-ins for site A using SQRL from my phishing site, site B. The users all believe (as with other phishing attacks) that they're being asked for credentials by a leg…
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 mor…
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.
Somewhat random thought: is Challenge-Response sufficient or should it be 'Challenge-Challenge-Response' so that the client only answers a challenge it requested? Otherwise, what's to stop an XSS attack on page A from effectively MITM page B by overriding the event listener for the login on page A, asking to sign for page B, then exfiltrating the response? EDIT: looks like the dialog attempts to give you some informa…
From what I understand, the way that FIDO defeats phishing is that it signs a response on the basis of the presented domain. If a phisher stands in the middle with a domain looks similar to human eyes to the legitimate domain, then the attacker is returning to the legitimate domain a response that was signed for the wrong domain, causing origin to reject the response. If your site makes it even remotely possible to h…
> If your site makes it possible to XSS the login page, you're doing login pages wrong.
Agreed, but the point was that a DIFFERENT service might be vulnerable and have XSS on their page which allows an attacker to request credentials for the real target. Your service isn't hacked, your users are.
> signs a response on the basis of the presented domain
This might do it, depending on what this means... Does this mean that if my address bar says `www.serviceA.com` that I include that domain in the response? Then if I asked the client for their credentials with a challenge and `rawId` (I think that's what identifies the relying party, IIRC) matching `www.serviceB.com`, it's possible that `www.serviceB.com` can reject the MITMed response because the attestation has the wrong domain. This is similar to JWT implementations only verifying the signature is valid and not checking that the signature type is the kind expected (i.e., not none). So, a weakness but nothing fatal.
I am curious how that works. I'll need to try it out.
Earlier quoted context omitted.
> FIDO tokens are very narrowly conceived to solve the exact second factor problem - and nothing else. Well, just that has been done completely flawlessly by smartcards for two decades already. Introducing a competing standard may just end with neither of them getting enough support.
Smartcards are not flawless, they never just work, there is always something that fails, I'm not saying that USB is flawless, but there is absolutely room for improvement here.
As simple as that.
https://caniuse.com/#search=webauthn
That's... actually not as bad as I was expecting it to be. If you're willing to limit your audience to modern browsers only, the only holdout is Safari; and on that score, what else is new.
Earlier quoted context omitted.
Formal as in Formal Mathematics -- a specification with a precise definition that can be verified by a model checker to have the desired safety and, if necessary, liveness guarantees.
Which flavour of Formal Mathmatical language would you suggest it should be written in?
I'd prefer TLA+ myself as the language, TLA, is straight-forward maths.
Earlier quoted context omitted.
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 mor…
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…
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.
Earlier quoted context omitted.
How would a magic link email be used with a password manager?
im talking products like notion that only support magic links (or google auth I guess but I’m not doing that). Slack does it right. You can use a magic link or use your password.