key systems rely on the user being able to verify that the URL is correct.) Disadvantages There are several drawbacks with digest access authentication: The website has no control over the user interface presented to the end user. Many of the security options in RFC 2617 are optional. If quality-of-protection (qop) is not specified by the server, the client will operate in a security-reduced legacy RFC 2069 mode Digest access authentication is vulnerable to a man-in-the-middle (MITM) attack. For example, a MITM attacker could tell clients to use basic access authentication or legacy RFC2069 digest access authentication mode. To extend this further, digest access authentication provides no mechanism for clients to verify the server's identity A server can store HA1 = MD5(username:realm:password) instead of the password itself. However, if the stored HA1 is leaked, an attacker can generate valid responses and access documents in the realm just as easily as if they had access to the password itself. The table of HA1 values must therefore be protected as securely as a file containing plaintext passwords. Digest access authentication prevents the use of a strong password hash (such as bcrypt) when storing passwords (since either the password, or the digested username, realm and password must be recoverable) Also, since the MD5 algorithm is not allowed in FIPS, HTTP Digest authentication will not work with FIPS-certified crypto modules. Alternative authentication protocols By far the most common approach is to use a HTTP+HTML form-based authentication cleartext protocol, or more rarely Basic access authentication. These weak cleartext protocols used together with HTTPS network encryption resolve many of the threats that digest access authentication is designed to prevent. However, this use of HTTPS relies upon the end user to accurately validate that they are accessing the correct URL each time to prevent sending their password to an untrusted server, which results in phishing attacks. Users often fail to do this, which is why phishing has become the most common form of security breach. Some strong authentication protocols for web-based applications that are occasionally used include: Public key authentication (usually implemented with a HTTPS / SSL client certificate) using a client certificate. Kerberos or SPNEGO authentication, employed for example by Microsoft IIS running configured for Integrated Windows Authentication (IWA). Secure Remote Password protocol (preferably within the HTTPS / TLS layer). However, this is not implemented by any mainstream browsers. JSON Web Token (JWT) is a JSON-based