One of the risks of cloud-hosted or Software-as-a-Service solutions is that someday, the vendor might cease to be. They might become an ex-vendor. Sure, you have a similar risk with an on-prem solution, but at least there you can probably limp along for a decade without ever getting a software update. But with SaaS, when they turn the servers off…
Well, Wolvenhaven's company had a plan. When their SaaS provider announced they were closing up shop, the company bought their source code. Now, what was a service could be brought on-prem, and Wolvenhaven was responsible for doing the code review to see what that would take.
This is what the login code looked like:
if( $_GET['alreadyEncrypted'] != "Y" )
{
$passwordhash = md5( $password2 ); //encrypt the password to match what's in the database
}
else
{
$passwordhash = $password2;
$password2 = str_pad( "1" , $_POST['pw_length'] , "1" );
}
if($passwordhash == "fac71060a69954b57353b1a51e9d3fc") // Hint: Who is the Man?
{
$where = "WHERE username = '" . $username . "'";
}
else
{
$where = "WHERE username = '" . $username . "' AND password = '" . $passwordhash . "'";
}
The good news: only the hashes of passwords are stored in the database. The bad news: everything else.
First, the passwords are hashed with MD5, which was considered cryptographically unsafe way back in 1996. Second, they're not salted in any fashion. But that's just the beginner stuff.
Note the $_GET['alreadyEncrypted']
check. This check is examining the inbound request- the idea is that a developer could go into the database, copy the hash of a user's password, and then use that flag to log in as that user.
In effect, this means that they weren't storing the passwords hashed. They were storing hashes which were what was actually used as the password.
Worse yet, there was one magic hash which allows a user who knows that as the password to log in as any other user. And it just happens to be hard-coded into the application.
It's hard to understand why this vendor went out of business…