How To Securely Hash Passwords In PHP?

Problem: Secure Password Hashing in PHP

Storing passwords securely is important for web application security. Hashing passwords helps protect user data from unauthorized access, even if the database is compromised. PHP developers need to use good hashing techniques to protect sensitive information.

Best Practices for Password Hashing in PHP

$salt = bin2hex(random_bytes(16));

PHP's Built-in Password Hashing Functions

$hashedPassword = password_hash($password, PASSWORD_DEFAULT);

if (password_verify($userInputPassword, $storedHashedPassword)) {
    echo "Password is correct!";
} else {
    echo "Password is incorrect.";
}

Configuring Hashing Options

$timeTarget = 0.05; // 50 milliseconds 

$cost = 8;
do {
    $cost++;
    $start = microtime(true);
    password_hash("test_password", PASSWORD_BCRYPT, ["cost" => $cost]);
    $end = microtime(true);
} while (($end - $start) < $timeTarget);

echo "Appropriate cost found: " . $cost;

function logHashTime($cost) {
    $start = microtime(true);
    password_hash("test_password", PASSWORD_BCRYPT, ["cost" => $cost]);
    $end = microtime(true);
    $time = $end - $start;

    error_log("Hash time for cost {$cost}: {$time} seconds");
}

// Log times for different costs
for ($cost = 8; $cost <= 15; $cost++) {
    logHashTime($cost);
}

Storing Hashed Passwords in Databases

When storing hashed passwords in databases, follow these best practices:

1. Use a column for hashed passwords. Create a column in your users table for storing the hashed passwords. This column should be VARCHAR with enough length to store the hash output (60-255 characters, depending on the hashing algorithm).

2. Store the full hash output. The output from password_hash() includes the algorithm, cost, and salt information. Store this entire string, as it's needed for password verification later.

3. Never store plain-text passwords. Always hash passwords before storing them in the database.

4. Use prepared statements. When inserting or updating password hashes in the database, use prepared statements to prevent SQL injection attacks.

5. Limit access to the password column. Use database permissions to restrict access to the password column to only the necessary database users or roles.

To avoid storage issues:

1. Don't shorten the hash. Some developers shorten the hash to save space. This breaks the hash and makes it unusable.

2. Don't use reversible encryption. Hashing is one-way and cannot be reversed. Avoid using encryption methods that can be decrypted.

3. Don't store the salt separately. Modern hashing functions like bcrypt include the salt in the hash output. There's no need to store it in a separate column.

4. Don't use old hash functions. Avoid using outdated functions like MD5 or SHA-1, which are not secure for password hashing.

5. Don't log or display hashed passwords. Treat hashed passwords as sensitive information and avoid including them in logs or displaying them in any user interface.

Handling Password Updates and Migrations

When upgrading password hashing algorithms or migrating to a new system, it's important to handle the process carefully to maintain security and minimize user impact. Here are some strategies for managing password updates and migrations:

Strategies for upgrading hashing algorithms:

• Gradual migration: Implement a system that can work with both old and new hashing algorithms. When users log in, check if their password is hashed with the old algorithm. If so, rehash it with the new algorithm and update the database.

• Flag system: Add a flag in your database to indicate which hashing algorithm was used for each user's password. This allows you to support multiple algorithms during the transition period.

• Forced password reset: For high-security systems, you might require all users to reset their passwords when upgrading to a new hashing algorithm. While this ensures immediate adoption, it can be inconvenient for users.

User password migration:

• Transparent updates: When a user logs in successfully with the old algorithm, rehash their password with the new algorithm without requiring any action from the user.

• Opportunistic migration: Update passwords to the new algorithm when users perform password-related actions, such as changing their password or requesting a reset.

• Background processing: For large systems, implement a background process that gradually migrates passwords to the new algorithm during off-peak hours.

Here's a PHP example of how to implement a gradual migration:

function verifyAndUpdatePassword($password, $hash) {
    if (password_verify($password, $hash)) {
        // Password is correct
        if (password_needs_rehash($hash, PASSWORD_DEFAULT)) {
            // Hash was created with an old algorithm, update it
            $newHash = password_hash($password, PASSWORD_DEFAULT);
            // Update the hash in the database
            updatePasswordInDatabase($newHash);
        }
        return true;
    }
    return false;
}

This function checks if the password is correct and, if so, checks if it needs to be rehashed with the current default algorithm. If rehashing is needed, it updates the hash in the database.

function migratePasswords() {
    $users = getUsersWithOldHashAlgorithm();
    foreach ($users as $user) {
        $newHash = password_hash($user['password'], PASSWORD_DEFAULT);
        updateUserPasswordHash($user['id'], $newHash);
        logMigrationProgress($user['id']);
    }
}

function logMigrationProgress($userId) {
    $log = "User ID: " . $userId . " - Password hash migrated at " . date('Y-m-d H:i:s');
    file_put_contents('migration_log.txt', $log . PHP_EOL, FILE_APPEND);
}

By using these strategies, you can upgrade your password hashing methods while minimizing disruption to your users and maintaining security throughout the migration process.