No data is entirely secure, and if anyone else has access to your webserver (the company managing the server for you?) or your database (the company storing the backups?) then you don’t have total control over the security anyway. So there’s always a chance your database could be stolen. So, the simple rule is to hash your passwords.

Hashing

A hash is a string derived from the original password via a one-way algorithm. In other words, it’s easy to create the hash from the original, but harder (when used for security, ideally impossible) to create the original from the hash. You store the hash in the database, and when the user signs-in you hash the password they sign-in with and compare it to the hash in the database. Something like this

if( $user->passwordhash == sha1( $_POST['password'] ) )

That way, you never store the user’s password.

There are a number of hashing algorithms in PHP, of which md5 and sha1 are the most commonly used. Unfortunately, neither is as secure as they were once thought to be. It would be better to use a more secure hash, and if you have the Hash engine in your PHP installation (included by default since PHP 5.1.2) then you have access to many more algorithms. So a better example would be

if( $user->passwordhash == hash( 'whirlpool', $_POST['password'] ) )

Rainbow tables

But there’s another problem. Once your database is stolen, the thief has plenty of time to crack the passwords using a simple Rainbow Table attack. This involves creating a large selection of hashes based on likely passwords (e.g. every word in the dictionary) and then comparing the hashes with the hashes in your database. Within an hour or so, half the passwords in your database will probably have been cracked.

To prevent this you should salt each password by adding a random string to it (called a salt or nonce). The time consuming part of a rainbow table attack is building the dictionary of hashes. Adding a random salt to the password means the thief has to build a whole new dictionary of hashes for each salt, making a rainbow table attack too time consuming to be viable. Each password should have a different salt, and the salt doesn’t even need to be secret.

The Code bit

So, for secure passwords you need code that looks something like this

// get a new salt - 8 hexadecimal characters long
// current PHP installations should not exceed 8 characters
// on dechex( mt_rand() )
// but we future proof it anyway with substr()
function getPasswordSalt()
{
    return substr( str_pad( dechex( mt_rand() ), 8, '0',
                                           STR_PAD_LEFT ), -8 );
}

// calculate the hash from a salt and a password
function getPasswordHash( $salt, $password )
{
    return $salt . ( hash( 'whirlpool', $salt . $password ) );
}

// compare a password to a hash
function comparePassword( $password, $hash )
{
    $salt = substr( $hash, 0, 8 );
    return $hash == getPasswordHash( $salt, $password );
}

// get a new hash for a password
$hash = getPasswordHash( getPasswordSalt(), $password );

You don’t have to attach the salt to the hash, you can instead store them separately within the database, but I like keeping them together in a single string. Equally, the salt needn’t be in hexadecimal, but I like the symmetry with the hexadecimal hash.

Finally, as Thomas Ptacek points out, you don’t want the fastest hash algorithm in the world for this – a fast algorithm is more useful to an attacker than it is to you.

There are a number of commercial and free obfuscating and encryption tools to help protect your code, three of which are ASO, SWFEncrypt and SecureSWF, so I’m not going to say any more about them (maybe in a later post). Here’s a few ideas for how to limit where the swf movie may be used.

What domain is the swf running in?

The swf can check to see what domain it’s running in and exit if the domain isn’t allowed. You can do this with a function like this

function isDomainAllowed( allowed:Array ):Boolean
{
    var lc:LocalConnection = new LocalConnection();
    var domain:String = lc.domain();

    for( var i:Number = 0; i < allowed.length; ++i )
    {
        if( domain == allowed[i] )
        {
            return true;
        }
    }
    for( var i:Number = 0; i < allowed.length; ++i )
    {
        if( domain.substr( - ( allowed[i].length + 1 ) ) )
                        == "." + allowed[i] )
        {
            return true;
        }
    }
    return false;
}

This function receives an array of allowed domains and checks the domain in which the movie is running against the array. If the swf is running in any of the domains or a subdomain of any of them then the function returns true, otherwise it returns false.

You use it like this

var domains:Array = new Array(
    "bigroom.co.uk",
    "example.com",
    "localhost"      // allow local testing
    );
if( isDomainAllowed( domains ) )
{
    gotoAndPlay( "content" ); // play the movie
}
else
{
    gotoAndPlay( "forbidden" ); // display some error message
                                // - more about this later
}

What flash player is the swf running in?

In the previous method, the localhost value in the array is to allow testing of the movie locally, in the Flash development environment or in a local web page. It also allows users to download the swf and run it locally or to load it into a projector. If you want to ban all local use of the swf then you can just remove the localhost value from the array of allowed domains. However, if you want to restrict the local use to some instances only (e.g. the Flash IDE only) you need to test what flash player the movie is running in. That works like this

function isPlayerAllowed( allowed:Array ):Boolean
{
    var player:String = System.capabilities.playerType;

    for( var i:Number = 0; i < allowed.length; ++i )
    {
        if( player == allowed[i] )
        {
            return true;
        }
    }
    return false;
}

The possible values of System.capabilities.playerType are

• ActiveX - the active-x control used in Internet Explorer
• PlugIn - the plug-in used in other web browsers
• StandAlone - the stand alone player and projectors
• External - the test movie mode in the Flash IDE

So the isPlayerAllowed function is used like this

var players:Array = new Array(
    "ActiveX",
    "PlugIn",
    "External"      // allow local testing
    );
if( isPlayerAllowed( domains ) )
{
    gotoAndPlay( "content" ); // play the movie
}
else
{
    gotoAndPlay( "forbidden" ); // display some error message
}

Load a file from the server

A third option is to try to load a file from your web server. If the load fails, abort the movie. Something like this

function testWithServer( callback:Function ):Void
{
    var receiver:LoadVars = new LoadVars();
    receiver.onLoad = callback;
    receiver.load( "http://example.com/testswf.txt" );
}

Which is used like this

function testResult( success:Boolean ):Void
{
    gotoAndPlay( "content" ); // play the movie
}
else
{
    gotoAndPlay( "forbidden" ); // display some error message
}

stop();
testWithServer( testResult );

This is quite basic - The file can be an empty text file - it needs no content. The function succeeds if the file can be loaded and thus is dependent only on the cross-domain policy for the domain hosting the test file that's loaded. If the policy allows the movie to load the file then it succeeds. The advantage to this is that we can update the allowed domains for our swf simply by modifying the cross-domain policy file on the server - there's no need to touch the flash movie. (More info on cross-domain policy files here)

It's important that the url is not a relative url - that would enable someone to bypass the security simply by placing an appropriate file on their own server.

There are many ways that this method can be enhanced, for example

• by sending the domain to the server and recieving a response that indicates whether the domain is allowed (and logging any disallowed domains)
• by generating a unique id each time the page containing the flash movie is loaded and passing it to the movie via the FlashVars. The swf then passes this back to the server when asking permission to run. The server allows each id to be used once only.
• by using encryption in the query and response (see ASCrypt for some actionscript encryption code).

But the basic system of an absolute URL and one or more (you can give each swf a unique policy file that it loads via the System.security.loadPolicyFile() method) cross-domain policy files is enough in many cases.

Conclusion

Each of these three ideas can be used individually or all together. Personally, I like the way that the first two are contained within the flash movie and require no special content on the server. Alternatively, the last method lets you update the allowed domains without editing the flash movie itself so each have their advantages. Note that if your source code can be decompiled then all these tests can be circumvented by simply removing the test altogether, so you may want to take another look at those encryptors and obfuscators.

What to do if playback isn't allowed?

If your test reveals that the movie shouldn't be allowed to play, then what should you do? There's two basic policies you could turn to

• Tell the user what's going on - display a message like "This movie/game/whatever can be viewed at http://example.com/funkyswf.html".
• Cause the player to crash - a simple while( true ); creates an infinite loop to achieve this.

I choose between these options based on specific circumstances. The second option gives a potential thief fewer clues as to what's going on, but you could use the first option to tell the thief where to legitimately obtain the swf (and how much it will cost).

I hope this is useful to you. What security techniques do you use?