Securing Drupal’s user login

Now that I managed to get SSL set up using a wildcard certificate (*.kkaefer.com) signed by CACert, securing the login to a Drupal site is amazingly easy:

# Force the user to use https.
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule /(user|admin) https://%{HTTP_HOST}%{REQUEST_URI} [R]

# Enfore SSL for user login and administration.
<LocationMatch "/(user|admin)">
    SSLRequireSSL
</LocationMatch>

That’s pretty much all you need. It works transparently for the user: When the user tries to access a URL beginning with admin or user, a redirect to the exact same request, but with http replaced by https is performed. Additionally, SSL is set to be required for those locations (I added that to prevent logins without SSL in case mod_rewrite fails, becomes unavailable etc.). You can easily add new paths that require SSL by just adding them to both regular expressions.

Sometimes users can login using a URL that doesn’t begin with user. Therefore you should also install securelogin.module which rewrites the actions of forms to use https.

Comments

1
Rajesh Akkineni on August 7, 2008

Thank you for the tip. It saved more than an hour for me.

2
Rajesh Akkineni on August 7, 2008

Where should I keep this rewrite code? I already have default .htaccess file and cleanURLs is enabled.

in .htaccess file I could not find the proper place to put this code. Can you suggest me?

Rajesh Akkineni

3
Konstantin on August 7, 2008

This can be either added to the beginning of the .htaccess file or the virtual server configuration in Apache’s configuration file.

4
don on August 14, 2008

Thanks for the info… We are getting ready to start developing in Drupal but we have been researching the differences between Drupal an WordPress… Can anyone provide any feedback between the pros and cons of each? Thanks!

5
Digital Business Views on October 10, 2008

Only topical experiences with Drupal, but remember it being very powerful, very full featured and almost overwhelming (likely only to the wimpy wannabe admins like me ;))

WordPress, on the other hand has a heck of a lot down under the hood. And they’ve coded the core so well, that the plethora of plugin (extensions or add-on modules) and themes have generated more opportunities than in any other Open Source CMS application that I’ve dealt with over the past 8 years or so.

The best way to truly compare these two, or any applications, is to just load them up, and dive in. Both are relatively easy to install (WP is VERY easy) and within moments you have the test beds to get the best kind of real world comparisons. I just go with the headache method: which app gives me a headache out of frustration or boredom first. Go with the other one!

6
IaN on November 1, 2008

Although I like this simple solution very much: Could it be that sensible data is posted over the web before the redirect takes place?

I mean: There’s a HTTP-request with password post or whatever, then, after the plain text request has reached the server, the server redirects to a secure connection…

A much better solution IMHO would be to configure Drupal itself to offer the possibility to generate https links in all login forms like popular shopping carts (e.g. os:C or xt:C) do, so that all sensible requests are sent over secure connections from the start.

Please correct me if I’m wrong in this point!

7
Konstantin on November 1, 2008

@IaN: You are absolutely correct about this. The last sentence of this blog post reads “Therefore you should also install securelogin.module which rewrites the actions of forms to use https.”. When the action of the form (the URL the form is posted to) is https, the information are not transmitted unencrypted in the first place.

8
IaN on November 1, 2008

Thanks, Konstantin. Unfortunately I’m using Drupal 6 and it seems there is no working SSL module by now for that branch…

9
Visitor on November 8, 2008

Thanks

10
Loretta Oliver on December 12, 2008

Thanks// working SSL module

11
Visitor on January 14, 2009

Please make sure that you set the secure flag of the cookie: http://drupal.org/node/357882