Elsewhere on this site we have described how cookies can be made more secure, or how logging into a Relying Party can be made secure against certain attacks. What we haven't talked about yet is how users authenticate to their Identity Providers in the first place. If malware or a man-in-the-middle can successfully attack the initial user authentication, then presumably all the other mechanisms described on this site don't help. Below we list some methods than can reduce, and in some cases eliminate, the risk associated with original user authentication. Password-Based Authentication in a Trusted EnvironmentIf during user authentication we can rule out the presence of a man-in-the-middle and malware, then the mechanisms presented on this site present good protection against future credential theft or session hijacking. There are certain situations in which the absence of attackers during user authentication might be a reasonable assumption - for example, when the user has to authenticate only once when he first uses a device, when the device is issued in a controlled way by enterprise IT staff, etc. Having to type passwords less often, and making login sessions longer, can help protect users here, as it reduces the probability that attackers are present during user authentication. In certain environments (e.g., enterprises) it might make sense to use certificates and TLS Client Authentication (or other similar technologies) to authenticate users. TLS Client Authentication protects against phishing and man-in-the-middle attacks, but as we mentioned elsewhere on this site, it's unsuitable as a mainstream authentication mechanism for the web. Two-Factor AuthenticationTwo-factor authentication usually requires presentation of a long-lived credential (the user's password, something that the user "knows") together with a short-lived or one-time-use credential (generated automatically by some device that the user "has") to gain access. Since the second credential is short-lived, theft of the combined credential usually doesn't give the attacker permanent access, somewhat alleviating issues with credential theft. Note, though, that both the long-lived and the short-lived credential could be phished, so even when using two-factor authentication, it might make sense to reduce the exposure of the credentials. FIDOOne of the most promising efforts in strengthening user authentication has recently been made by the FIDO Alliance. FIDO defines user authentication protocols that are privacy-preserving (e.g., credentials are scoped to a single web site), yet move beyond bearer tokens such as passwords or one-time-PINs that are used today in most second-factor systems. FIDO interacts with Token Binding in an interesting way: a FIDO assertion proves that the client is in possession of a key pair that identify a certain user to the web server: the web server sends a challenge to the client, and the client responds with a signature over that challenge. That signature (or FIDO assertion) includes the origin of the web server, which makes FIDO assertions (unlike 2-factor OTPs) resistant to phishing. The FIDO assertion is also short-lived, which means it will be of no use to thieves after a certain amount of time. To reduce the risk of assertion theft even further, FIDO also interfaces with Token Binding directly, by signing (in addition to the server's challenge and the origin) over the client's Token Binding key. This binds the FIDO assertion to the HTTPS channel between the client and the server - any attempt to use the assertion from a different channel will not succeed. Token Binding and FIDO have been designed to work together to rid the web of bearer tokens: FIDO replaces passwords (or augments them) with phishing-resistant and man-in-the-middle-resistant cryptographic assertions, and Token Binding augments cookies with man-in-the-middle-resistant cryptographic assertions. |