Proxy Authentication Typesby G.S. Jackson
Proxy servers route Internet traffic for various reasons. You might use a proxy server to hide your Internet Protocol address while browsing, as the IP address of a proxy server will substitute for your own. Other times, however, local area networks use proxy servers to control traffic in and out of a network. In these cases, authentication is typically required. This authentication can come by way of simple passwords or more comprehensive authentication suites such as NT LAN Manager or Kerberos.
While not, strictly speaking, a type of authentication, the state of nonauthentication in proxy servers has a particular class, called the "transparent" proxy. This sort of proxy does not necessarily require a user authentication, but forces particular users into particular networks based on their identities, and as such usually involves some sort of authentication. This typically works through verifying users based on IP address.
A simple form of proxy authentication is simple password authentication. In order to use the proxy server, you have to provide a username and password. This measure can keep unwanted users out. However, password authentication suffers from a few pitfalls, namely that passwords are often easy to break and only offer a single level of security. Usually, you should package password authentication with another authentication measure for two-step authentication.
Microsoft NTLM involves password authentication coupled with a challenge/response algorithm. After you log on to the NTLM server, the server sends an package of data based on the password and username used, as well as on the domain of the server. Your client application must encrypt the data and send it back to the server. If the server can decrypt it using its key, then your computer has been authenticated to use that proxy.
Kerberos, developed at MIT, works in a similar fashion as NTLM. When your client application tries to use a Kerberos proxy, it files a ticket with the server. The server uses the information on the ticket to encrypt a package of data, which it sends back to your client application. The client application must decrypt the ticket using a shared authentication key. The decrypted data now represents an authorization ticket that allows your computer access to use the Kerberos server.