@nobackseat is very correct here.
Affirmation/Clarification for anyone unaware:
Hashing algorithms are a branch of cryptographic algorithms, definitely not "encryption" as the input for these algorithms are not designed to be reversed.
Best practices in handling passwords is to NEVER email passwords. Email is not a secure channel of communication, even if your mail server reaches out over SSL initially. You never know how email gets routed after it leaves your network.
If the use of the word "unhash" means to be equivocal to "decrypt", there is a fundamental misunderstanding somewhere here. Due to the rare potential of collisions in hashing algorithms, you can't assuredly get the original input for a resulting hashsum. The only way to this very day to reverse engineer the input from a hash table is by either pre-computed (think rainbow table lookups) or active brute forcing.
When it comes to handling passwords, you as an entity do not want to know the user password or transmit it. You only want to receive it as input and forget that input immediately. Ideally if you can receive some form of token, a token would be better than a password for security. Especially if it's like the tokens provided by Google Authenticator or one of the RSA algorithms.
Failure to do anything less than forgetting the password as soon as you receive it results in more vectors of vulnerability that an intruder can use to exploit your user base. As a result, this also has vast legal implications.
Lets Talk About Cryptography! (I like crypto! WOO!)
Going to try to stay pretty broad here. Generically the very fundamental meaning of cryptography is to use an algorithm to take input and yield an output that is indistinguishable from the initial input. These algorithms are known as ciphers.
Most ciphers aim to typically achieve 1 of two potential goals which are encryption or message verification.
The AES cipher intends to take input and provide ouput that can only be deciphered if you know the key used to make the output. Typically you will see ciphers for this intended us are rooted deeply in symmetric algorithms, where you have one algorithm for encryption with at least 2 inputs (message, key) and another algorithm for decryption the requires at least 2 inputs (encoded_message, key). The actual math used between the encryption and decryption assumes a shared number of sorts.
The SHA family of ciphers take input and provide what is known as a hash sum that can not be deciphered by design. Most hashing algorithms are intended for verifying authenticity of a message (or some other input). Hashing algorithms typically have a form of recursion, so that after iterating input, math can still continue to product output. Before output is provided, it is expected that only part of the yielded sum from whatever math is being done gets arbitrarily lopped off. A really major use of hashing algorithms right now is in cryptocurrencies, due to the inherent nature of verifying data on a block chain.
There's a lot more to this topic really, because there's so many ciphers with varying degrees of purpose, in addition to cipher suites (just tool kits essentially), that provide tools for signing, verifying, encrypting, decrypting, and even doing math on encrypted data. If you ever want to learn more, I highly recommend picking up some blockchain knowledge. The simplest "Writing your own Blockchain" guide I ever read that explains it decently is probably here: https://medium.com/@mycoralhealth/code-your-own-blockchain-in-less-than-200-lines-of-go-e296282bcffc
Back to the topic at hand? (lol)
So to kinda roll this back into the original discussion, @Design1online you are writing a VPG framework? Is this on github? I'm been a fan of what I have watched @owlmanatt do historically with making KittoKittoKitto and he's like low key working on ZuttoZuttoZutto from what I can tell.