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, 2017 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, 2017 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, 2017 at 21:55
  • Sounds like a better, more secure, approach. Thank you.
    – Rich
    Aug 13, 2017 at 22:17

1 Answer 1


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, 2017 at 21:04
  • Is pre_user_pass and undocumented filter? I can't seem to find any references to it. Thanks!
    – Rich
    Aug 13, 2017 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, 2017 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, 2017 at 22:27
  • That information isn't passed, you'll need to figure it out via other means
    – Tom J Nowell
    Aug 13, 2017 at 23:10

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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