I'm using Advanced Custom Fields to make some sort of personal database of my logins. ACF has a password-field type which works great, but it stores the data in plain text to the database. So I found this topic which enables us to hash the password before sending it to the database:

function at_vault_encrypt( $value, $post_id, $field  )  
       $value = wp_hash_password( $value ); 
       return $value;  
 add_filter('acf/update_value/type=password', 'at_vault_encrypt', 10, 3);  

This function uses the wp_hash_password functionality and applies it to the ACF update filter. The core of my question is this: Can I un-hash it when the data get's shown in the backend?

The problem is when I save an item with password and reopen it, it shows the hashed password instead of the one I entered. This foregoes the whole point of noting the passwords if I can't read them out later.

So I figured I might 'de-hash' the passwords, but that doesn't seem an option. Maybe this is taking WordPress too far and it can't be rightly done, it's just an extra security measure not to have the fields saved plaintext in the database.

(PS. I'm not here to start a discussion on data-security. I'm well aware of passwords managers and other (maybe more secure ways) to do this).

  • Please, include the code you use to hash the password (not all hashing methods can be reversed, which it is a intended behaviour) and explain the question/problem in a way that it is WordPress specific, without involving third party plugins; if the answer needs to know how a third party plugin works, the question fall to off-topic category.
    – cybmeta
    Oct 28, 2016 at 9:26
  • @cybmeta - sorry if I was unclear, the topic has nothing to do with ACF directly, the core of the question is about wordpress core functionality wp_hash_password. I updated the question for clarity.
    – Asitis
    Oct 28, 2016 at 10:32
  • 1
    You get the same security storing the plaintext passwords in your database when compared to a string that can be decoded back to its original value: none.
    – Daniel
    Oct 28, 2016 at 13:13

2 Answers 2


By definition, hashing is one-way ecnryption, so it can not be reversed (maybe some super hacker can do it, but it should be very difficult or almost imposible to do). It is not a bug, problem or somehting like that, It is the intended behaviour and it how every site should work.

Many people use same password across several services, so no one, including the site owner, should be able to know a user's password. Imaging that the site is hacked, if the passwords can be reversed, the hacker could have access to all passwords, and potentially not only for your site. Or simply a site owner could use the user's password to access user's account in other sites.

So, if you hash a password with wp_hash_password(), or any other hashgin method, and you can not decrypt it, it is exactly like it is designed.

You may be interested in encryption instead of hashing, a method that can be reversed only if the rules applied to do the encryption are known, usually by using secret keys. You can do it in PHP, for example, with mcrypt_encrypt()/mcrypt_decrypt(). But it is not safe for users, because the site owner can know his/her password; use it if you need to keep confidentiality but not integrity.

Or you may be interested in encoding, but encoding is just plain text in another format that a human may not read directly, but just because it is not used to it, not because it is secure or encrypted in some way, that is why it can easily decoded by converting back to the original format (that is, you get zero security).

Some ready to use encoding methods in PHP:

  • 1
    Thanks for the clear info, I see now (and amused I didn't see this logic before) that what I'm asking is 'impossible' in the sense that it eventually is the same as plain-text saving it.
    – Asitis
    Oct 28, 2016 at 15:17

Hashes are not meant to be reversible. Instead, you could use an encoding scheme like Base64 for storing your information:

// Encode
function at_vault_encode( $value, $post_id, $field  ) {  
  return base64_encode($value);
add_filter('acf/update_value/type=password', 'at_vault_encode', 10, 3);

// Decode
function at_vault_decode( $value, $post_id, $field  ) {  
  return base64_decode($value);
add_filter('acf/load_value/type=password', 'at_vault_decode', 10, 3);

However, it's important to note that this way of storing passwords is just as insecure as storing plaintext strings.


Your Answer

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

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