Converting Rail’s RESTful Authentication to PHP

A few months back we were rebuilding an existing site; the mandate was to use PHP for the upcoming release, but the existing site used Ruby on Rail’s RESTful Authentication gem to encrypt user passwords against a unique salt. Each user had both an encrypted password and a salt value that was being updated every time the user successfully logged in. Pretty smart.

Our problem was that we had to re-create the hashing of the user’s password so existing users could log into the site using their old password. With the code below, we are able to hash the user’s entered password in the same way that the Rails app did, allowing authentication to function properly in the new application. Fortunately the existing application used the default hashing method (we didn’t have access to the old site’s source code), so it was just a matter of digging around GIT to understand how the hashing process worked.

1
2
3
4
5
6
7
8
9
10
11
<?php
// $salt variable as retrieved from user's row based on supplied email address
$salt = '36493cef361b8b180863fe3e2685473f676359df';

$password = $_POST['password'];

//NOTE: this assumes a default Restful Auth setup
$password = sha1('--' . $salt . '--' . $password . '--');

//supplied password should now match encrypted database value if entered correctly
?>

2 Comments

  1. Boob says:

    “Each user had both an encrypted password and a salt value that was being updated every time the user successfully logged in. ”

    I don’t understand the cleverness in this statement – are you saying the salted value is being handed back and forth, or just that the salt in the database is being updated? If it’s the latter, wouldn’t that still make it as vulnerable as if the salt never changed? If a hacker got the salt+salted value at any given time, they can still crack the password locally. Just curious what’s going on there.

    • kettle says:

      @Boob
      Sorry, that was poorly written; by encrypted I meant hashed. I have updated the post to reflect that.

      Just the salt in the database is being updated. Typically with most out of the box authentication systems I’ve seen, there is a single salt value for an entire application. User passwords are stored hashed against that single salt. Problem here is that if a single user is compromised, someone can work backwards and compromise all other users. This approach means the salt for each user is different.

      Changing the salt every time a user logs in means that hijack-and-replay vulnerabilities exist only as long as the logged in session.

Leave a Reply