Authentication Mechanisms – How Secure are They?

Authentication Mechanisms – How Secure are They?

Hello everyone!

Recently, I’ve been reading about the Digest Authentication mechanism (RFC 2617) after reading the Account Password Policy section of the Windows Local Computer and Group Policy Object (GPO) editors piqued my interest.

RFC 2617 describes two primary authentication methods: Basic and Digest.

Basic Authentication

Basic is as simple as it is insecure. Basic transfers the specified username and password in PLAINTEXT unless of course surrounded by a layer of encryption such as SSL/TLS. Which I’d STRONGLY recommended you use for virtually ANY type of website. Trusted SSL/TLS certificates can be gotten for free thanks to the Let’s Encrypt project and you can also self-sign your own if only a select group of people are going to use it.

Digest Authentication

Digest Authentication is much different then it’s basic counterpart. Before sending anything to the authenticating server. The Digest method hashes the username and password using a hashing algorithm.

One important facet of this authentication method is that the client and server must agree on a hashing algorithm prior to authentication. Most commonly this is MD5, which is what is used as an example in the RFC 2617 document.

Microsoft provides a mechanism for user authentication as part of their ASP.NET framework. Similar mechanisms are also available from libraries from Ruby on Rails, Angular, and many other frameworks as well.

My Objection

While the Digest authentication method sounds perfectly secure in theory. However, in practice MD5 is no longer considered secure by modern standards. The massive collection of rainbow tables pretty much means that most passwords that users are likely to use can be easily extrapolated from a stolen database.

This can be negated by the use of adding salt to the passwords before sending them though the hash algorithm and in most cases, you should be doing this anyways. However, that does not always mean that people are doing it.

The Digest authentication method can also support using another hashing algorithms other then MD5 (such as SHA-2, SHA-256, SHA-512, Whirlpool, etc., etc.). As long as the client and the server both support it. But since the official RFC 2617 documentation uses MD5 as an example. I would wager a guess that most people use MD5 for their digests. It is the most commonly used Digest hashing algorithm after all.

Now again, if you are storing passwords using a salted hash function this shouldn’t be a problem. You should also use SSL/TLS wherever possible regardless of your authentication algorithm (remember, authentication is almost entirely useless if the traffic is not encrypted.).

Connecting Back to GPOs

However in an interesting twist, Microsoft has the option to store Windows passwords using reversible encryption rather then using the default, non-reversible NTLM hashed encryption used by Windows both in the enterprise Active Directory environments and by standalone personal Windows desktop computers.

As you may or may not know, the Windows Local Computer and Group Policy Object (GPO) editors features a quite detailed description of each policy. Which is a quite handy feature to Windows system administrators.

When you go to the password policy settings using the GPO editor (found in Computer Configuration>Windows Settings>Security Settings>Account Policies>Password Policy in the GPO editor snap-in in MMC). You will read that not only can Internet Authentication Services (IAS) module in IIS and Challenge-Handshake Authentication Protocol (CHAP) be used to authenticate users in Active Directory. But doing so also requires that the “Store Windows passwords using reversible encryption” policy be enabled. Which personally I find to be kind of confusing.

I really don’t understand why such a policy would need to be adopted in order to authenticate users using IIS or though CHAP. MIcrosoft owns the ASP.NET framework and they designed the CHAP protocol. So really I have no idea why it wouldn’t support the use of NTLM.

Does it have something to do with Kerbros? Do most web browsers not support Kerbros? And must therefore fall-back to the Basic (plaintext) authentication mechanism?

What do you think? Let me know in the comments.

Leave a Reply