Moving from a non WordPress site to a WordPress Site – Login between both sites

WordPress’s code to verify passwords is wp_check_password. You’ll see that this uses phpass:

require_once ABSPATH . WPINC . '/class-phpass.php';
// By default, use the portable hash from phpass.
$wp_hasher = new PasswordHash( 8, true );

$check = $wp_hasher->CheckPassword( $password, $hash );

which is class-phpass.php in the WordPress code which at first glance looks like it has no WordPress function dependencies and you can just take the whole file.

Note though that you can also modify this code to match your existing passwords if you have them available to WordPress somehow: you could either

1. add your own authenticate hook, like the default wp_authenticate_username_password

   // Default authentication filters.
   add_filter( 'authenticate', 'wp_authenticate_username_password', 20, 3 );
   

   that would check your own password hash and return a populated WP_User object if it matches

2. hook the check_password filter, which is called at the end of wp_check_password after it has tested the hash:

   /**
     * Filters whether the plaintext password matches the encrypted password.
     *
     * @since 2.5.0
     *
     * @param bool       $check    Whether the passwords match.
     * @param string     $password The plaintext password.
     * @param string     $hash     The hashed password.
     * @param string|int $user_id  User ID. Can be empty.
     */
    return apply_filters( 'check_password', $check, $password, $hash, $user_id );
   

   If the $check value passed in is false then that means the password didn’t match the hash using WordPress’s algorithm: you could then test the password against the hash using your existing logic and return true if it matches that.

That way your users could keep their existing passwords. Your code that matches the existing hashes could then write a new-style hash into the user object if you wanted since it has the clear password to hand, or you could just keep matching the existing passwords.

The code to check the cookies is a bit more involved, alas. It’s wp_validate_auth_cookie. If you follow this through, you’ll see that

• the cookie is called wordpress_<hash> or wordpress_sec_<hash>, depending on whether you’re using HTTPS or not, where the hash part is the MD5 of the site URL
• it is split into four pipe-separated parts
  • username
  • expiration date
  • session token – must match a value in the ‘session_tokens’ wp_usermeta for the user
  • authenticated hash – an MD5-HMAC of the other three components, plus four characters from the user’s password hash (so that cookies are invalidated on password changes), using either AUTH_KEY or SECURE_AUTH_KEY from wp-config as the HMAC key

I suspect you’d do best extracting the relevant parts of the WordPress code rather than trying to reimplement this, or even calling out to the WordPress instance somehow.

However once again you can extend WordPress to accept your existing cookies too: in this case you want to hook determine_current_user.