The pull request included the code that does the hashing:-
if( empty( $auth_pass ) || ( isset( $_POST['pass'] ) && ( md5($_POST['pass']) == $auth_pass ) ) )
$_SESSION[md5($_SERVER['HTTP_HOST'])] = true;
else
printLogin();
So any salt [was hash] used would have to be present in the code too.Given that such a simple password (8 digits) could be brute forced in seconds on an average PC, even with a salt, it doesn't really matter whether it was salted or not.
A password of "p*l12nJ9£l ~98as2389bvkqsopfq£3oef2[olpe]wog!wei^og(8ni" would take an unrealistic amount of time to brute force, even if unsalted, and it's beyond the scope of any precomputed rainbow tables for similar reasons.
Anyway, it's only a concern if he uses the same password elsewhere.
Since rainbow tables look up a password via its hashed value, I believe you could find something else that has a hash collision -- for all we know, it has the same hash as 'ponies'.
The sheer size of the keyspace (2^128) means that rainbow tables can only ever exist for a subset of the keyspace.
1M machines running for a year each capable of doing 20M MD5 hashes a second will still only cover 1/539514153540300709th of the MD5 keyspace.
But, yes, salting would prevent the use of rainbow tables completely.
Hash type: MD5, Hash: 6df23dc03f9b54cc38a0fc1483df6e21
Device #0: [RV870] 850.00 Mhz 1600 SP
Device #1: [RV870] 850.00 Mhz 1600 SP
CURPWD: @uX5G DONE: 22.30% ETA: 1m 34s CURSPD: 6436.3M=3217.8M+3218.6M
http://www.golubev.com/hashgpu.htm