Was bored; Made an Encryption site.

[Objected]

Generate the hash in JS and then do an asynchronous callback to the server side so that the password is displayed to the user without having to let him wait.

Also, if you're going to be storing people's passwords and allowing others to decrypt them not a lot of user are going to make use of this except for hashing other things than passwords.

Thanks for the reply, but I think you may have gotten the wrong idea about the site.

Due to the fact that passwords are encrypted in MD5, SHA512, SHA1, and MySQL5's PASSWORD() function, I figured, "Hey, what if people want to crack passwords?", so I inserted the 2 million passwords. It does serve as a place to encrypt strings, regardless if they're passwords or not, but it can also serve as a place to attempt to decrypt passwords.

Answered that above as timebomb was writing about how passwords shouldn't be stored in plain-text, and such.

[Objected]

I'm either stuck because it's so easy, or stuck because there's no way to do it.

After continuing to reprogram the website, I made a function called dehash();

This function takes one parameter; the hash. The function as it stands is only a prepared SQL statement, with a parameter binding in place.

function deHash($Hash)
{
    $Get = $this->DB->prepare("SELECT COUNT(hash_id), plain_text, hash_md5, hash_base64, hash_sha1, hash_sha512, hash_mysql FROM hashes WHERE ...");
    $Get->bind_param("s", $Hash);
    $Get->execute();
    $Get->bind_result($Count, $text, $md5, $b64, $sha1, $sha512, $mysql);
    $Get->fetch();
    $Get->close();
} 

The table structure is as jMerlin suggested, since it was the best that I could think of at the time. The table structure is as follows:

hash_id int(11)
plain_text varchar(100)
hash_md5 varchar(32)
hash_base64 varchar(500)
hash_sha1 varchar(50)
hash_sha512 varchar(128)
hash_mysql varchar(50)

Since the user would just enter a hash to decrypt it against the database, I thought about it, and came up with the thought that I would have to use multiple OR statements in the SQL query, and check EACH column for the hash.
This, most likely, would take up more time than I want it to take, so therefore, I'm asking. Is there a simpler way to do this?

[TimeBomb]

I'm either stuck because it's so easy, or stuck because there's no way to do it.

After continuing to reprogram the website, I made a function called dehash();

This function takes one parameter; the hash. The function as it stands is only a prepared SQL statement, with a parameter binding in place.

function deHash($Hash)
{
    $Get = $this->DB->prepare("SELECT COUNT(hash_id), plain_text, hash_md5, hash_base64, hash_sha1, hash_sha512, hash_mysql FROM hashes WHERE ...");
    $Get->bind_param("s", $Hash);
    $Get->execute();
    $Get->bind_result($Count, $text, $md5, $b64, $sha1, $sha512, $mysql);
    $Get->fetch();
    $Get->close();
} 

The table structure is as jMerlin suggested, since it was the best that I could think of at the time. The table structure is as follows:

hash_id int(11)
plain_text varchar(100)
hash_md5 varchar(32)
hash_base64 varchar(500)
hash_sha1 varchar(50)
hash_sha512 varchar(128)
hash_mysql varchar(50)

Since the user would just enter a hash to decrypt it against the database, I thought about it, and came up with the thought that I would have to use multiple OR statements in the SQL query, and check EACH column for the hash.
This, most likely, would take up more time than I want it to take, so therefore, I'm asking. Is there a simpler way to do this?

... the database will pull the plain text password and requested types of encryption, pass it to JS, and JS will render the encrypted/hashed password.

​​​​​

[Objected]

​​​​​

But what if the user who didn't encrypt the hash wants to decrypt it? It'll be a different scenario due to the fact that the hash they give us via the site will be checked against 5 different columns to find the plain text. The problem is that the check against the 5 columns would take more time than I need it to take, so I'm hoping that many someone has a solution to such a problem.

[TimeBomb]

But what if the user who didn't encrypt the hash wants to decrypt it? It'll be a different scenario due to the fact that the hash they give us via the site will be checked against 5 different columns to find the plain text. The problem is that the check against the 5 columns would take more time than I need it to take, so I'm hoping that many someone has a solution to such a problem.

You aren't supposed to be able to reverse a hash. As s-p-n already said, hash != encryption.
You are talking about rainbow tables, i.e. you put in a hash and it is compared against a known list of hash/nonhashed pairs.

I highly suggest you keep the rainbow table aspect of your site separate from the encrypting/hashing aspect - at least in terms of database organization.

[Objected]

You aren't supposed to be able to reverse a hash. As s-p-n already said, hash != encryption.
You are talking about rainbow tables, i.e. you put in a hash and it is compared against a known list of hash/nonhashed pairs.

I highly suggest you keep the rainbow table aspect of your site separate from the encrypting/hashing aspect - at least in terms of database organization.

From what I realize, I've already mentioned that I've done this concept (rainbow tables) throughout the whole site; nothing else.

When a user encrypts a string, if that string isn't already in the database, the string is added so that it may decrypted later.

Due to the fact that passwords are encrypted in MD5, SHA512, SHA1, and MySQL5's PASSWORD() function, I figured, "Hey, what if people want to crack passwords?", so I inserted the 2 million passwords. It does serve as a place to encrypt strings, regardless if they're passwords or not, but it can also serve as a place to attempt to decrypt passwords.

This website is about the same concept as MD5Decrypter.co.uk, Over 8.7 billion Decrypted Hashes, Free MD5 Decryptor, MD5 Cracker, MD5 Security Hacking, MD5 Encryption: Encrypt & Decrypt MD5 Hashes, except my hash site has 5 hashes to support. Get it?

[jMerliN]

There's no point. You can't deal with salting, and nobody stores plain hashes anymore.