0

Disclaimer: I'm fully aware of the security issues created by this. This is not for production.

Whenever a new user is registered or a password is (re)set in WordPress I'm attempting to also capture that password, encrypt it, and save it to the wp_usermeta table.

I've had success hooking into the profile_update action to accomplish this, but the above process only works if a password is changed from the profile page and does not account for new user registrations.

add_action( 'profile_update', 'save_encrypted_passwords_to_usermeta' );

function save_encrypted_passwords_to_usermeta( $user_id ) {
    if ( isset( $_POST['pass1'] ) ) {
        $password = $_POST['pass1'];
        update_user_meta( $user_id, 'password', $password );
    }
}

I've looked to the pluggable function wp_set_password() to accomplish this and have created this muplugin which doesn't seem to work at all.

function wp_set_password( $password, $user_id ) {
    global $wpdb;
    $hash = wp_hash_password( $password );
    $wpdb->update($wpdb->users, array('user_pass' => $hash, 'user_activation_key' => ''), array('ID' => $user_id) );
    update_user_meta( $user_id, 'password', $password );
    wp_cache_delete($user_id, 'users');
}

I'm assuming wp_set_password is always called when a password is created or set so I'm not sure why my pluggable function override is not at all working.

  • What is the reason for doing this? – Tom J Nowell Aug 13 '17 at 20:53
  • Reason: An Admin creates user accounts for users which do not have an email address (a fictitious catch-all address is used). The Manager for this site is responsible for remembering the user's usernames and passwords in case a user forgets but does not have the ability to change them. This is not for a public website. – Rich Aug 13 '17 at 21:11
  • 1
    Could you not generate a reset URL that the admin can hand to the users? This way they can set a new password without it being revealed or having duplicated storage, and the admin need never know what the passwords are – Tom J Nowell Aug 13 '17 at 21:55
  • Sounds like a better, more secure, approach. Thank you. – Rich Aug 13 '17 at 22:17
0

No, I would expect wp_user_update to have been what gets used, but I find your motives dubious, and cannot think of a reasonable use for what you want to do

But if you really want to go down this path, use the pre_user_pass filter.

I would also note that there is a reason why passwords are stored as hashes, rather than encrypted, and your code has no encryption mechanism

  • gist.github.com/salipro4ever/db1a7eeb237df5834f33 is the encryption mechanism I'm using. I removed it from the code example above to simplify. – Rich Aug 13 '17 at 21:04
  • Is pre_user_pass and undocumented filter? I can't seem to find any references to it. Thanks! – Rich Aug 13 '17 at 21:19
  • See github.com/WordPress/WordPress/blob/… it doesn't appear verbatim, it's a generated filter name, and not a commonly used one either – Tom J Nowell Aug 13 '17 at 21:54
  • pre_user_pass seems to be the best possible solution to date. Can you enlighten me as to how I can pass the $user_id into the filter? – Rich Aug 13 '17 at 22:27
  • That information isn't passed, you'll need to figure it out via other means – Tom J Nowell Aug 13 '17 at 23:10

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.