HTTP Response Header: Content-Disposition

For the longest time, I always wondered how WordPress.org always served the current version of wordpress from a file named “latest.tar.gz”, and whenever I downloaded it with a browser (such as Firefox), my browser would always save it as something like “wordpress-3.5.2.tar.gz” instead. This never happened when I would retrieve the file using “wget”. I never really bothered looking into it much.

Just tonight I stumbled across it while downloading a driver for a USB wireless adapter that I have.

It’s all in the “Content-Disposition” header, which can contain an optional “filename” field tagged on to the end. The “filename” field is just a suggestion to the browser for a filename to save the file as. It’s not mandatory, and apparently “wget” doesn’t give a hoot about it. Well, I don’t like my packages having filenames like “dl.php”, so I dug in a bit and learned what made this happen.

(I need to rename “dl.php” to something else, and I wanted to find the suggested filename.)

Here’s a sample of what the Content-Disposition HTTP response header may look like when downloading a file with a suggested filename:


Content-Disposition: attachment;filename=Package-2013_07_08.dmg

Password Policy

Hackers/crackers use modern GPUs (and possibly ASICs) to brute-force passwords. The old-school password policies from the early 2000’s really shouldn’t apply now, because to a computer, it’s irrelevant which characters are which. Computers can run through the entire UTF-8 charset in fractions of a second, and they’ll eventually guess a short password whether or not it contains a mix of character types (upper, lower, numbers, special, etc).

I’m tired of seeing password policies like this (I saw this when trying to change one of my passwords today):

We require that your new password contain the following:

2 upper case letters
2 lower case letter
2 numbers
2 special characters (examples: !@#$%^&*)

This leads to a false sense of security on both the part of users and the site operators.

Anyone still using/enforcing/advocating this kind of password policy needs to read this (I promise it’s very short).

It doesn’t have to be that complicated. I’ve boiled it down to a 2-step process:

  1. enforce a minimum password (or passphrase) length, such as 25+ characters
  2. hash the password using bcrypt or scrypt and store only the hash

Obviously basic steps should be taken, such as preventing passwords from being transmitted in plaintext, but the 2 measures above will prevent 99% of passwords from being cracked.