Passwords – Storage

Here’s a quick rundown of some of the common ways to store a password in a database, and a few considerations:

Clear text

If you store your passwords in cleartext, you probably should find someone else to do the coding for your projects. I won’t go into the risks – you’ll find them out soon enough.

Hashed

Running the passwords through a hashing function such as MD5, SHA-1, or SHA-256 will create one-way hashed representations of the original password.

The danger here is precomputed rainbow tables – you take a dictionary or all the combinations of letters and numbers up to a certain length and hash each word to check against later.

This has already been done for most combos of letters, and is freely available (and even indexed by Google – check out the funny and somewhat scary BozoCrack project).

Hashed (salted well)

You can make the stored hashes less likely to be looked up by salting the hashes by appending a string to the term that is going to be hashed.  You’ll need to store the salt somewhere so you can re-append when checking against this value at a later time.  This makes the hash for a particular word different than it would have been by itself, and less prone to automated lookup.

Be sure to use a long and randomized salt when you do this, as it is trivial to compute lookup tables for given salt values, and for most shorter or simple salts, tables have already been generated.

Hashed (salted well and uniquely)

You can drastically improve the security of your stored hashes by simply using a long, randomized, and unique salt for each row, rather than one salt for the entire database.

Doing this would require the generation of lookup tables for each hashed password in your database, rather than creating just one lookup table that would be applicable to the entire database.

Hashed (salted well and uniquely) + key stretching

Using a method such as PBKDF2, you can add an additional complicating factor: time.

By adding an iteration count to your hashing method, rather than running the hash once, you run it potentially thousands of times, with the result of each previous run feeding the next. The idea is to increase the amount of time to generate a hash to something unnoticeable to a human, say half a second to a whole second to generate the hash, but expensive timewise to repeat many times.

By doing this, you dramatically increase the time it would take to create a lookup table for a particular salt. You can also keep abreast of Moore’s Law by increasing your iteration count every few years and rehashing.

The Remake: Keeping It Simple

When the time came to redo this site, the sheer number of options available made for a bit of a difficult decision in terms of what to use, so I did what any reasonable programmer would do and put it off for a few months while I did anything but.

Once I came around, I started to evaluate.

There are a sizeable number of frameworks and blogging tools that can fit the bill of powering a site as small as this, most being fine examples of overkill for my needs.

In the end, since this site is so small, I decided to try out a PHP-based microframework.

Slim Framwork

I wanted to try something new, which effectively discounted a few otherwise excellent PHP-based options such as Expression Engine (overkill for my needs), WordPress (awesome, but I’ve used that in most previous incarnations of this site), and CodeIgniter (also probably overkill).

The desire to use something fairly minimal pointed me in the direction of something like Limonade, Slim, or a Ruby based microframework like Sinatra or Jekyll.

Since I do a lot of PHP in my day-to-day, I ended up trying out the Slim, and am very happy thus far.

Twig Templating Engine

Twig was completely new to me, but every single tutorial I found about Slim ended up recommending Twig as the templating engine, despite the fact that it supports several others (like Smarty, so I took the hint.

As with other templating languages, Twig lets you set template variables for your templates, and provides you with a number of looping and conditional constructs and filters to manipulate those variables within your templates.

It also implements an intuitive way of extending base templates with other templates, giving you an easy way of establishing layouts and encouraging reuse.

There’s way more once you get down below the surface, but that’s all I’ve done at this point, and it got me far.

Markdown Syntax

I use Markdown within the Twig templates to write the blog posts on this site. I just preprocess it with Slim, using a library I found here, which works very well.

The beauty of Markdown is how readable it is before it gets parsed by anything at all. You can write a document in Markdown that is perfectly legible, and then pass it through any convenient Markdown library to turn it into HTML that is clean and consistent.

Awesome, and hard to screw up.

EDIT: the site is now in something else, heh – needed more experience managing Drupal, so here we are.

Passwords – Quality

September 15th, 2012 by Phil Pelanne

I just did a quick presentation at work about password security, and how to help cover your own ass when it comes to passwords. After some sad statistics about the state of affairs in the space (people steal passwords a lot, and service providers don’t store them very well), it closed with some management suggestions, since the way you manage passwords is about the only thing you can control.

In short:

  • One password per online service, no exceptions. Compartmentalize your accounts, so that if someone stores your stuff in cleartext and it gets stolen, that password won’t get the attackers into any of your other services.
  • Don’t use silly mnemonic devices to create secure passwords. You’ll never generate as high quality passwords in as much quantity as you need. Use password generation tools to create them for you.
  • Use a password manager to remember your passwords for you – don’t clutter your brain with connections between services and passwords. It’s a losing battle. Check out solutions like Lastpass, 1Password or Keepass. Be sure your master password is freaking awesome.
  • Make your passwords long – it’s trivial to generate lookup tables for passwords of less than ten characters. GPUs are getting faster all the time, so if possible, just max out the password length a service provides.
  • Make your passwords complicated. Lowercase passwords net you 26 possibilities per character. Mixed case + numbers + ascii keyboard characters nets you 96 possibilities per character. For a ten character password, that improves things from taking mere hours to compute all the possible hashes to taking hundreds of years to do it (at least for now).
  • Enable two-factor authentication on as many services that support it as possible. This way even if someone gets your login and password, they’d have to have your phone or something else in order to actually get in.

Rackspace Cloud Files CDN Edge Purge

We occasionally use Rackspace Cloud Files to serve up static content, and sometimes we need to make a change and want that change reflected immediately (frequently for things like css or js files). This doesn’t always jive with a CDN’s normal caching of such assets for long periods of time.

Some solutions to this are to rename the file on the CDN and then update references to it, or to add an argument to references to it like “?v=2”.

Or you can force its removal using the Cloud Files API, and this can be done fairly easily from the command line in two commands:

First, just log in to get your Auth Token, for which you’ll need your API key (which you’ll found in the RS Clound management console):

curl -IL –header “X-Auth-User: <your-user-name>” -H “X-Auth-Key: <your-api-key>” https://auth.api.rackspacecloud.com/v1.0

You’ll get back a response which will contain your Auth Token and your CDN Management URL which you use in the next request in conjunction with the container and optional file you want to purge:

curl -D – -X DELETE -H “X-Auth-Token: <your-auth-token>” -H “X-Purge-Email: <email@domain.com>” https://cdn.clouddrive.com/v1/<account-id>/<container>/<filename>

Sending that will return you a response telling you that your file is queued for removal. You’re supposed to get an email too, if you send the purge-email header (though I didn’t).

If you leave the filename off of the end, it will queue everything in the container for purging Otherwise, it will purge the single file.

It generally takes a few minutes, but then the file is gone and the next request will fetch it anew, to much rejoicing.