Indigo Server authentication

I am working on an python wrapper around the Indigo Restful interface, and discovered that the Indigo Server requires remote logins to be with a Digest based password.  Is this good?  Yes, indeed it is.  Digest authentication is designed to be the significantly more secure and when your talking about the security of your home authomation you would prefer it to be secure.

But what is Digest Access Authentication?  The digest access authentication was originally speced in RFC 2069.  In this, the password is encrypted by a nonce (Number used once), and is used to calculate a MD5 digest of the password.  So no plain text passwords, and due to the nonce (among other things) your password is not a simple reversible hash.

What does the Nonce do to help?  Why a Nonce?  This makes the encryption key change each time there is a authentication challenge, and thus making replay attacks, and dictionary attacks, virtually impossible to break the encryption.

But this security is not impossible to defeat.  If your password is too simple, for example, 12345.  In theory, an attacker could attempt an brute force attack, and see if they could match an valid password digest.

Advantages

HTTP digest authentication is designed to be more secure than traditional digest authentication schemes; e.g., “significantly stronger than (e.g.)CRAM-MD-5.

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 to store HA1 rather than the cleartext password.
  • Client nonce was introduced in RFC2617, 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, which is extremely weak. 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.