Wordpress sha 256 login

Question

I've been asked to enable SHA256 for storing wordpress passwords. I've searched for plugins with no luck (not working), so I started to develop my own.

I first thoug.. well if I replace the wp_hash_password with my own function, It would encrypt when saving password and loging. But I wasn't that lucky. I'm able to run hash(sha256) though in a basic php file. I'm aware that users wont' be able to login as the stored key would be md5 and the comparation would be SHA, but it isn't a problem.

Code:

 if(!function_exists('wp_hash_password')):
   function wp_hash_password($password){
     return hash('sha256', $password);
   }
endif;

So I guess I'll have to make my own "check login" function. Did someone did something like this?¿

Answer 1

Seems to me that your approach should work if you override the wp_check_password function as well. That'll have to be done in a plugin, I think, as the functions are loaded before the theme's functions.php. Something like this:

<?php
/*
Plugin Name: sh256pass
Version: 1.0
*/

if(!function_exists('wp_hash_password')):
   function wp_hash_password($password){
     return hash('sha256', $password);
   }
endif;


if(!function_exists('wp_check_password')):
    function wp_check_password($password, $hash, $user_id = '') {
        // You might want to apply the check_password filter here 
        return wp_hash_password($password) == $hash;
    }
endif;

Note that you'll either have to have your users reset their password on their next login (you won't be able to convert the existing passwords automatically), or you'll have to follow WordPress's approach in wp_check_password and compare the password to the old encrypted value (in their case md5), and if that matches, update to the new value.

Keep in mind that the wp_users.user_pass field is only 64 characters long. While that's (just) long enough to store the sha256 value, it isn't long enough to store the sha256 value and a salt. If you don't salt, and two users choose the same password, the wp_users.user_pass field will contain the same value, making it obvious to anyone with access to the database that the passwords are the same. My gut feel is that that is a greater security risk than using the current algorithm. You might be able to get around that by (say) concatenating the user ID and the password before hashing, but there might be edge cases where you don't know the user ID (such as when a user is created).

Personally, I'd question the requirement.