Solutions

MarkLogic Data Hub Service

Fast data integration + improved data governance and security, with no infrastructure to buy or manage.

Learn More

Learn

Stay On Top Of Everything MarkLogic

Be the first to know! News, product information, and events delivered straight to your inbox.

Sign Me Up

Community

Stay On Top Of Everything MarkLogic

Be the first to know! News, product information, and events delivered straight to your inbox.

Sign Me Up

Company

Stay On Top Of Everything MarkLogic

Be the first to know! News, product information, and events delivered straight to your inbox.

Sign Me Up

 
Knowledgebase:
Using Basic Authentication over HTTPS in place of HTTP Digest Authentication
31 October 2019 12:40 PM

Introduction

MarkLogic AppServer supports several authentication methods such as Basic, Digest, Kerberos, and in more recent years, SAML and Certificate-based authentication.

The two most common authentication methods are Basic and Digest authentication and the choice of which to use has often come down to security considerations; Basic Authentication uses a simple Base64 encoding to convert the userid and password in an HTTP Authorization header.

Unfortunately, the encoding process is not secure and it is a minor procedure to decode the header to reveal the actual userid and password.

To guard against the weaknesses of the Basic Authentication encoding process, Digest Authentication was developed to make use of new cryptographic hashing advancements and nonce values to prevent replay attacks and this became the authentication choice for most MarkLogic users wishing to secure access to their AppServers.

However, over time Digest Authentication has not been without problems; many of the security options specified within the Digest Authentication protocol are considered optional and, therefore, subject to implementation and compatibility differences between software products.

MarkLogic Server: Hardening Digest Authentication

With security in mind, MarkLogic made a number of changes to harden the Digest Authentication protocol used within the server from the 9.0-3 release and above; specifically, MarkLogic server now verifies the nonce, checks that the nonce is not being used as part of a replay attack, and verifies that the URI in the Authorization header is the same as the originating request URI.

Unfortunately, this has caused issues with some client software and libraries, which were not themselves securely implementing the Digest protocol. Most issues can usually be addressed by ensuring you are running a current version of your client software; however, there are occasions where problems can still occur, such as being repeatedly prompted to enter your userid and password.

Considerations for introducing HTTPS / TLS

If you are affected by Digest Authentication issues with MarkLogic, it is worth considering switching back to Basic Authentication with the addition of securing the connection between the client and MarkLogic AppServer using TLS, i.e., Basic Authentication over HTTPS.

This will mitigate against the one original reason for using Digest over Basic Authentication in that it will prevent the Basic Authorization header from being disclosed and thus prevent decoding from taking place. In addition, unlike Digest Authentication, Basic Authentication over HTTPS not only protects the user credentials but also encrypts the payload being transmitted, which in itself may also contain sensitive information.

If you are still not convinced to convert from Digest Authentication to Basic Authentication over HTTPS then it is also worth considering the fact that the Digest Authentication protocol is probably nowhere near as secure today as you might think, to the point that Digest-MD5 - on which most the HTTP Digest Authentication is based - is now considered obsolete and deprecated due to a high number of security deficiencies that make it vulnerable to attack as detailed in RFC-6331 

From RFC-6331 section 6, 7 and 8

6. DIGEST-MD5 outer hash (the value of the "response" directive) does not protect the whole authentication exchange, which makes the mechanism vulnerable to "man-in-the-middle" (MITM) attacks, such as modification of the list of supported qops or ciphers.

7. The following features are missing from DIGEST-MD5, making it insecure or unsuitable for use in protocols:

A. Channel bindings [RFC5056].

B. Hash agility (i.e., no easy way to replace the MD5 hash function with another one).

C. Support for SASLPrep [RFC4013] or any other type of Unicode character normalization of usernames and passwords. The original DIGEST-MD5 document predates SASLPrep and does not recommend any Unicode character normalization.

8. The cryptographic primitives in DIGEST-MD5 are not up to today's standards, in particular:

A. The MD5 hash is sufficiently weak to make a brute force attack on DIGEST-MD5 easy with common hardware [RFC6151].

B. The RC4 algorithm is prone to attack when used as the security layer without discarding the initial key stream output [RFC6229].

C. The DES cipher for the security layer is considered insecure due to its small key space [RFC3766].

Note that most of the problems listed above are already present in the HTTP Digest authentication mechanism.

References

(1 vote(s))
Helpful
Not helpful

Comments (0)