1. Basic access authentication
In the context of an HTTP transaction, basic access authentication is a method for a web browser or other client program to provide a user name and password when making a request.
Before transmission, the user name is appended with a colon and concatenated with the password. The resulting string is encoded with the Base64 algorithm. For example, given the user name 'Aladdin' and password 'open sesame', the string 'Aladdin:open sesame' is Base64 encoded, resulting in 'QWxhZGRpbjpvcGVuIHNlc2FtZQ=='. The Base64-encoded string is transmitted in the HTTP and decoded by the receiver, resulting in the colon-separated user name and password string.
While encoding the user name and password with the Base64 algorithm makes them unreadable to the unaided eye, they are trivially decoded by software. Confidentiality is not the intent of the encoding step; HTTP in general does not provide such guarantees (see HTTPS). Rather, the intent of the encoding is to encode non-HTTP-compatible characters that may be in the user name or password into those that are HTTP-compatible.

One advantage of the basic access authentication is all web browsers support it. But due to the fact that the username and password are passed in cleartext, it is rarely used by itself on publicly accessible Internet web sites. However, it is somewhat commonly found on publicly accessible sites if combined with SSL/TLS (HTTPS). One other advantage of basic authentication is that it avoids the double hop authentication problem that can cause problems for protocols such as NTLM.

Disadvantages
Although the scheme is easily implemented, it relies on the assumption that the connection between the client and server computers is secure and can be trusted. Specifically, if SSL/TLS is not used, then the credentials are passed as plaintext and could be intercepted.
Existing browsers retain authentication information until the tab or browser is closed or the user clears the history.[3] HTTP does not provide a method for a server to direct clients to discard these cached credentials. This means that there is no effective way for a server to "log out" the user without closing the browser. This is a significant defect that requires browser manufacturers to support a "logout" user interface element or API available to JavaScript, further extensions to HTTP, or use of existing alternative techniques such as retrieving the page over SSL/TLS with an unguessable string in the URL.

2. NTLM
In a Windows network, NTLM (NT LAN Manager) is a suite of Microsoft security protocols that provides authentication, integrity, and confidentiality to users. NTLM is the successor to the authentication protocol in Microsoft LAN Manager (LANMAN), an older Microsoft product, and attempts to provide backwards compatibility with LANMAN. NTLM version two (NTLMv2), which was introduced in Windows NT 4.0 SP4 (and natively supported in Windows 2000), enhances NTLM security by hardening the protocol against many spoofing attacks, and adding the ability for a server to authenticate to the client.
While Kerberos has replaced NTLM as the default authentication protocol in an Active Directory based single sign-on scheme, NTLM is still widely used in situations where a domain controller is not available or is unreachable. For example, NTLM would be used if a client is not Kerberos capable, the server is not joined to a domain, or the user is remotely authenticating over the web.
Protocol
NTLM is a challenge-response authentication protocol which uses three messages to authenticate a client in a connection oriented environment (connectionless is similar), and a fourth additional message if integrity is desired. First, the client establishes a network path to the server and sends a NEGOTIATE_MESSAGE advertising its capabilities. Next, the server responds with CHALLENGE_MESSAGE which is used to establish the identity of the client. Finally, the client responds to the challenge with a AUTHENTICATE_MESSAGE.
The NTLM protocol uses one or both of two hashed password values, both of which are also stored on the server (or domain controller), and which are password equivalent, meaning that if you grab the hash value from the server, you can authenticate without knowing the actual password. The two are the LM Hash (a DES-based function applied to the first 14 chars of the password converted to the traditional 8 bit PC charset for the language), and the NT Hash (MD4 of the little endian UTF-16 Unicode password). Both hash values are 16 bytes (128 bits) each.
The NTLM protocol also uses one of two one way functions, depending on the NTLM version. NT LanMan and NTLM version one use the DES based LanMan one way function (LMOWF), while NTLM version two uses the NT MD5 based one way function (NTOWF).
Vulnerabilities
NTLM is widely deployed, even on new systems, often for compatibility with older systems. But it remains vulnerable to a credentials forwarding attack, which is a variant on the reflection attack which was addressed by Microsoft security update MS08-068.

3. Kerberos (protocol)
Kerberos is a computer network authentication protocol which works on the basis of "tickets" to allow nodes communicating over a non-secure network to prove their identity to one another in a secure manner. Its designers aimed primarily at a client–server model, and it provides mutual authentication—both the user and the server verify each other's identity. Kerberos protocol messages are protected against eavesdropping and replay attacks. Kerberos builds on symmetric key cryptography and requires a trusted third party, and optionally may use public-key cryptography by utilizing asymmetric key cryptography during certain phases of authentication. Kerberos uses port 88 by default.
MIT developed Kerberos to protect network services provided by Project Athena.
Protocol
The client authenticates itself to the Authentication Server (AS) which forwards the username to a Key Distribution Center (KDC). The KDC issues a Ticket Granting Ticket (TGT), which is time stamped, encrypts it using the user's password and returns the encrypted result to the user's workstation. If successful, this gives the user desktop access.
When the client needs to communicate with another node ("principal" in Kerberos parlance) it sends the TGT to the Ticket Granting Service (TGS), which shares the same host as the KDC. After verifying the TGT is valid and the user is permitted to access the requested service, the TGS issues a Ticket and session keys, which are returned to the client.
The client then sends the Ticket and keys to the service server (SS).

4. Digest access authentication
Digest access authentication is one of the agreed-upon methods a web server can use to negotiate credentials with a user's web browser. It applies a hash function to a password before sending it over the network, which is safer than basic access authentication, which sends plaintext.
Technically, digest authentication is an application of MD5 cryptographic hashing with usage of nonce values to discourage cryptanalysis. It uses the HTTP protocol.
Process
* The client asks for a page that requires authentication but does not provide a username and password. Typically this is because the user simply entered the address or followed a link to the page. * The server responds with the 401 "client-error" response code, providing the authentication realm and a randomly-generated, single-use value called a nonce. * At this point, the browser will present the authentication realm (typically a description of the computer or system being accessed) to the user and prompt for a username and password. The user may decide to cancel at this point. * Once a username and password have been supplied, the client re-sends the same request but adds an authentication header that includes the response code. * In this example, the server accepts the authentication and the page is returned. If the username is invalid and/or the password is incorrect, the server might return the "401" response code and the client would prompt the user again.

Advantages
HTTP digest authentication is designed to be more secure than traditional digest authentication schemes; e.g., "significantly stronger than (e.g.) CRAM-MD5 ..." (RFC2617 ).
Some of the security strengths of HTTP digest authentication are: * The password is not used directly in the digest, but rather HA1 = MD5(username:realm:password). This allows some implementations (e.g. JBoss DIGESTAuth ) to store HA1 rather than the clear text password. * Client nonce was introduced in RFC 2617, which allows the client to prevent Chosen-plaintext attacks (which otherwise makes e.g. rainbow tables a threat to digest authentication schemes). * Server nonce is allowed to contain timestamps. Therefore the server may inspect nonce attributes submitted by clients, to prevent replay attacks. * Server is also allowed to maintain a list of recently issued or used server nonce values to prevent reuse.
Disadvantages
Digest access authentication is intended as a security trade-off. It is intended to replace unencrypted HTTP basic access authentication. It is not, however, intended to replace strong authentication protocols, such as public-key or Kerberos authentication.
In terms of security, there are several drawbacks with digest access authentication: * 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. * Some servers require passwords to be stored using reversible encryption. However, it is possible to instead store the digested value of the username, realm, and password.