Where are the points at which you can throw a spanner into the works of a federated phish (fphish?) (that for which OpenID gets attacked but other browser-redirect SSO protocols are vulnerable).
0) in the email app
- this is status quo
1) at the initiating RP?
- the phish presumes the RP is bad.
2) at the client?
- by having sufficient client smarts to either passively recognize (and warn) or actively circumvent (by not allowing the client to be sent to the phish site) a phish
3) at the IDP?
- by the IDP using an authentication mechanism that is phishing proof/resistant, i.e not reliant on a shared secret (Infocard)
- by the IDP using an authentication mechanism that constrains the damage of a phish (OTP)
- by recognizing the presentation of phished credentials (pattern analysis?)
4) at a secondary (authentic) RP?
- by recognizing a federated claim arising from the presentation of phished credentials? Good luck.
My money is on the client.
No comments:
Post a Comment