I have been looking around the core files searching for hooks, there were very few when it comes to hooking into edit_user() function which updates the user data in profile.php page, so I have finished with some workarounds:
My workaround is to save the user’s password in a custom option before the password was updated, and match later with this user’s password to see if it has changed:
add_action("check_passwords", function( $user_login, $pass1, $pass2 ) {
if ( !is_admin() || !defined('IS_PROFILE_PAGE') || !IS_PROFILE_PAGE )
return; // not profile.php page, let's mind our business
update_option( "_se_debug_user_submitted_pass", wp_get_current_user()->user_pass );
return;
}, 10, 3);
add_action("admin_init", function() {
global $pagenow;
if ( "profile.php" !== $pagenow ) return;
global $current_user;
if ( get_option( $opt_name = "_se_debug_user_submitted_pass" ) && (string) get_option( $opt_name ) !== (string) $current_user->user_pass ) {
// the password has changed.
echo "Password has changed!";
/* do things here */
delete_option( $opt_name ); // do only once
}
});
That should work and as long as in profile.php page (updating own profile).
To capture the password, after this line:
update_option( "_se_debug_user_submitted_pass", wp_get_current_user()->user_pass );
update a custom option with the new password value $pass2 which is the password confirmation, and call this option within // the password has changed. wrap. THIS IS NOT GOOD AT ALL to get user’s plain text passwords, I would never recommend such thing but it’s your call and on your own risk. Unless you are capturing the hashed pass then that’s totally fine.
One thing is, if the user updates the password but still with the same old pass, this condition will still be fired because the WordPress password hashing system uses randomly-generated salts and therefore the return will be different (powerful security, and I would like to invite you to quit using md5 if you use it for hashing in your projects).
Hope that helps somehow.