That htpasswd file of yours has got to go

If you’re my sort of nerd (which I suspect many of my readers are), this story or something like it will probably have happened to you.

Flashback: the summer of 2009. I’m setting up a private website, access for which needs to be restricted to a handful of friends. So I do the obvious thing:

htpasswd -c /srv/auth/my-site.htpasswd david

The htpasswd tool allows you to maintain a simple file of usernames and password hashes, then you just hook it up to your Apache (other web servers are available) with a few lines of config, like this:

<Location /private/>
    AuthType Basic
    AuthName "Top secret"
    AuthUserFile /srv/auth/my-site.htpasswd
    Require valid-user
</Location>

And now, when you visit the location, your browser pops up the usual dialog box:

The ’90s called, they want this dialog box back

Maybe, like me, you rounded it off by providing a simple scripted interface for users to reset their passwords if they forgot them.

And there the matter rested, in my case for over a decade. However, logging in to the aforementioned site yesterday, I realised there are several things wrong with all this (seen with the benefit of, ahem, 2020 hindsight):

  • Most password managers can’t fill in the dialog box most browsers use for HTTP basic authentication, so you have to copy/paste (or worse, use a well known password and never change it)
  • Why does a dinky little private site I run which we all use twice a year need its own password database? Yet another thing to remember, or risk people re-using a password on. Is it using an up to date, properly salted password hashing mechanism? I don’t even know.
  • This doesn’t allow for two factor authentication, which I view as practically mandatory for internet-facing systems these days.

Like me, you’ve probably had a vague intention to retire your various examples of this setup for years, but have been put off from doing so because it’s not clear what else can be done without adding a huge pile of complexity. Perhaps I can help you with that…

By using the mod_auth_openidc Apache module, you can swap basic auth for “sign in with Google” in about ten minutes.

Their site explains how. Don’t be put off by the references to the now-defunct Google+; the underlying APIs still exist and work. I did have to work out a couple of extra tweaks:

    OIDCRemoteUserClaim email
OIDCScope "openid email"

It’s not the nicest Apache module I’ve ever worked with, as it will segfault the process if you get its configuration wrong (e.g. leaving out the above). It also needs extra config if you’re running behind a proxy and the user-facing port number is different to the back end. But still, it’s packaged for Debian and once you have it working, it stays that way.

Finally, if you don’t have a Google Apps domain with all your users in it, and instead just want to restrict people to signing in with a whitelist of allowed Google/GMail accounts, you simply do this:

Require user [email protected] [email protected]

Result. Naturally, as well as meaning one fewer account for your users to worry about (realistically, they all had Google accounts already), this means that password reset, second factors, etc. etc. are all now Google’s problem, not yours.

Go get rid of your basic auth; the rest of the internet thanks you in advance.