I'd like to see securesite.module support Digest auth in addition to Basic auth. The server admin should be able to select the auth scheme to use.

A brief overview of Digest auth is at http://en.wikipedia.org/wiki/Digest_access_authentication and it's defined in RFC 2617 (http://tools.ietf.org/html/rfc2617). In addition to the Basic auth stuff, securesite.module needs to do some md5 encoding/decoding, as well as creating random salts. It should be possible within the existing framework.

Comments

Darren Oh’s picture

Finding a way to implement digest authentication and improve Drupal’s security presents a dilemma. Currently, users’ credentials are not stored on the server, and therefore cannot be stolen. On the other hand, users must send their credentials across the network, so it is possible for their credentials to be intercepted.

Digest authentication does not require users to send their credentials across the network, but does require their credentials to be stored on the server. This makes it possible to steal users’ credentials from the server.

To enable digest authentication, we would have to previously have saved users’ credentials. On a new site this could be done at registration. On an existing site it would have to be done at log-in, which would mean that we could not force digest authentication.

Darren Oh’s picture

Status: Active » Closed (won't fix)

naquah rejected this feature for the HTTP authentication module. I’m going to follow his lead for now.

Darren Oh’s picture

Priority: Normal » Minor
Status: Closed (won't fix) » Active

Just occurred to me that we can provide a table of users for whom we do not have credentials so that administrators can see who would be locked out of the site if digest authentication were forced and decide accordingly.

Darren Oh’s picture

Added in CVS commit 142120.

Users' passwords are stored when they log in or change their passwords. Passwords are currently stored in the securesite table, but a more secure solution needs to be found, otherwise any user who has permission to use the PHP filter will have access to every other user's password. Users whose passwords have not been stored can cancel the HTTP authentication dialog and log in with the HTML form.

Junyor’s picture

Considering that we'd have to store the passwords separately for this to work, I think it's a good idea to not include Digest Auth. I don't like the idea of having to store and maintain the password twice.

I had not realized this would be the case when I filed the feature request.

Darren Oh’s picture

This is doable. We can add a field to the administration page where the user can enter the path to a script that will handle the digest authentication. The script would allow passwords to be stored but not retrieved. When given digest credentials, it would simply return TRUE or FALSE to indicate whether the log-in is valid.

Junyor’s picture

That seems like a completely separate module, though. I skimmed the 6.x-2.0 code and don't see any way to authenticate against the server for HTTP Auth. Were you planning to add that to obsolete HTTP Auth?

Darren Oh’s picture

HTTP basic authentication is still there. I renamed _securesite_user_auth() to _securesite_dialog(). I moved the authentication code from securesite_boot() into two separate functions: _securesite_digest_auth() and _securesite_basic_auth(). When the user supplies digest credentials, _securesite_digest_auth() checks for a stored password and re-calculates the digest to see if it matches. When the user supplies a password, _securesite_basic() performs an ordinary log-in.

Junyor’s picture

Right, but we're not authenticating against the server (i.e. using .htaccess), but against the Drupal database. But your proposal for Digest is to authenticate against the server, correct?

Darren Oh’s picture

No, Apache's digest authentication isn't flexible enough. Changing the realm expires the passwords. We'd run into the same problem we had with basic authentication: in most browsers users couldn't log out. I'll modify the current database table and authentication code so it does what we need an external program to do, and then work on creating the program or pursuading someone to create it.

OpenLDAP may be capable of doing what we need for those who use LDAP authentication. I'll look into it.

Junyor’s picture

Cool.

Darren Oh’s picture

CVS commit 142934: Moved password handling to _securesite_digest_manage(). This function now stores passwords and validates digests and nonce values as our external program needs to do.

Darren Oh’s picture

Digest authentication through LDAP is supported in PHP by ldap_sasl_bind(). It is not yet supported by the LDAP integration module, however.

NaX’s picture

I know I am a little late to the party here, but here are my 2cents.

As you guys have already discussed there are some problems with Digest Authentication.

However I did find this Class, http://www.xiven.com/sourcecode/digestauthentication.php

If you look at the notes section of the comments, the Author of the class does talk about the problems of Digest Authentication and browser issues. He recommends SSL, and this makes sense SSL + Basic Auth is more secure than Digest by it’s self. On that note I think we should look at documenting and/or adding support (if required) for the Secure Pages module. Ubercart recommends Secure Pages for credit card transactions and I think it has some integration with it but I don’t know much about that.

But I don’t think we need to worry about Apache or an external application for all this. Looking at “Example #2 Digest HTTP Authentication example” on http://www.php.net/features.http-auth they have the username and password setup in an array. I don’t know much about all that md5 stuff going on, I have not read up that much on Digest Authentication but that example gives me hope that this would be much simpler. I think we would just need to store the md5 password hash when users are added to Drupal.

When it comes to ldap_sasl_bind(), I think this is most definitely something that would be useful. Secure site + ldap makes a very good pare in a Corporate environments, if we can add SASL based authentication it would great. This would have to be part of the ldap module unless somebody can see another way round that. Also it’s seems new and badly documented. I could only find the following example.
http://www.washington.edu/computing/eds/php-ldap-sasl.html

That said, I don’t think this would be hard to add to ldap, it’s a pity I don’t have an ldap server to play with or I could look into this a little more. The way I see it, once you have your ldap resource object setup, you just have to setup the LDAPTLS environment variables and then call the ldap_sasl_bind() function. The hard part in all this is the LDAP server setup.

But there are a lot of options if you look at all the SASL mechanisms available http://en.wikipedia.org/wiki/Simple_Authentication_and_Security_Layer

Looking at OpenLDAP + SASL http://www.bind9.net/manual/openldap/2.2/sasl.html
They recommend Kerberos but the minimum LDAPv3 supports is DIGEST-MD5. They don’t support anything less secure.

So adding Digest authentication through ldap and sasl would be nice but I think we would have to also look into the other 2 recommended and OpenLDAP supported mechanisms, Kerberos and EXTERNAL.

I hope all that makes sense?

Darren Oh’s picture

In cases where the user does not send a password, there is no getting around the need to store a shared secret on the server. The PHP manual's example stores it in the code, which does not provide sufficient security. I would like to use SASL for both normal and LDAP authentication.

Darren Oh’s picture

Status: Active » Fixed

Added external scripts in CVS commit 148171.

Anonymous’s picture

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for two weeks with no activity.

  • Commit 66243b9 on 6.x-2.x, 7.x-2.x, master, 8.x-1.x by Darren Oh:
    #136822 by Darren Oh: Added external scripts for secure password...
  • Commit 7fb971d on 6.x-2.x, 7.x-2.x, master, 8.x-1.x by Darren Oh:
    #136822 by Darren Oh: Added support for HTTP digest authentication....