Show User Their Password

I’ve got a few automated scripts that run to notify users of certain updates to the application, etc… and for one in particular, I need to be able to display the users user_login and their password.

How do I show the user their password if it’s encrypted?

Related posts

Leave a Reply

2 comments

  1. Theoretically, this could be achieved by saving a user’s password elsewhere, when he or she updates it.

    Note that this sort of thing is hardly ever recommendable.
    In almost all cases, there is a better architectural approach that renders having to be able to show plain-text passwords unnecessary.

    That being said, if you absolutely must do it, this is how it could be done:

    funtion wpse_97127_save_passes( $errors, $update, $user )
    {
        if (
            empty( $errors->errors ) &&
            ! empty ( $_POST['pass1'] )
        ) {
            /* if you must save it in reversible form, at least don't save it in plain-text */
            $pass = base64_encode(
                mcrypt_encrypt(
                    MCRYPT_RIJNDAEL_256,
                    md5(AUTH_KEY),
                    $_POST['pass1'],
                    MCRYPT_MODE_CBC,
                    md5(md5(AUTH_KEY))
                )
            );
            // do something with $pass, i.e. save it somewhere
        }
    }
    add_action( 'user_profile_update_errors', 'wpse_97127_save_passes', 0, 3 );
    

    The above can be reversed like so:

    $pass_from_db = $wpdb->get_results( /* retrieve encrypted, but reversible pass from db*/ );
    $pass = rtrim(
        mcrypt_decrypt(
            MCRYPT_RIJNDAEL_256,
            md5(AUTH_KEY),
            base64_decode($pass_from_db),
            MCRYPT_MODE_CBC,
            md5(md5(AUTH_KEY))
        ),
        ""
    );
    

    Please do not do this in production environments with user accounts of individual entities without their consent or knowledge. That would not only constitute bad practice, but also be an unethical deed.

    I do the above in exactly one case with one specific user role, the capabilities of which are limited , new users of which are always set up by an admin or other higher level role, and the password of which is shared with multiple people in the first place.
    And still I do not feel good about it.

  2. User passwords are stored in the database as what is called a hash. hashes are not reversible even if you know the hash and the mechanism used to create it. The only way to “decrypt” a hash is to take a password, hash it, compare it against the target hash, and try again… over and over until you get a match. If you think about that, you aren’t really decrypting at all. It is just brute force trail and error.

    The plain text password is never saved and you should not attempt to save it as that undermines the security of the site, and as people tend to reuse passwords the security of a lot of other sites as well.