3 ms·
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 w
by solatic 8y ago
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 have an XSS attack on the login page (by not being a separate page with no user-provided input apart from the login credentials) then you're doing login pages wrong to begin with.
- eximius 8y agoI'm not sure this addresses my point. > 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.