Encryption? Salt? Secret Key? Whaaat?

[StevenOliver]

If I insert plaintext into a mySQL table, hackers could break in and read all my tables.

I searched the net and found the encryption and decryption functions listed below where I can ENCRYPT the data before inserting into the mySQL table.

What I don't understand is the "$secretKey = md5('secretWord');" part....

If a hacker is smart enough to break into my system and read all my mySQL tables, the hacker will surely be able to read the "$secretKey = md5('secretWord');" line of code and see the secret word!

What am I missing?

$secretKey = md5('secretWord');

function encryptate($string, $secretKey) {
$passcrypt = mcrypt_encrypt(MCRYPT_RIJNDAEL_256, $mc_key, trim($string), MCRYPT_MODE_ECB);
$encoded = base64_encode($passcrypt);
return $encoded;
}

function decryptate($string, $secretKey) {
$decoded = base64_decode($string);
$decrypted = rtrim(mcrypt_decrypt(MCRYPT_RIJNDAEL_256, $mc_key, $decoded, MCRYPT_MODE_ECB));
return $decrypted;
}

[benanamen]

md5 ? decrypting passwords? Whaaat? Just toss this code right now and learn how to use password_hash and password_verify like the rest of us.

Edited October 12, 2018 by benanamen

[requinix]

38 minutes ago, StevenOliver said:

If I insert plaintext into a mySQL table, hackers could break in and read all my tables.

More like "if you insert plaintext and if hackers break in, they could read all the passwords".

39 minutes ago, StevenOliver said:

If a hacker is smart enough to break into my system and read all my mySQL tables, the hacker will surely be able to read the "$secretKey = md5('secretWord');" line of code and see the secret word!

Not necessarily. Most "hackers" get into your database. Getting into your code is much harder.

That code came up with a dumb key used for encryption and decryption, but like benanamen said you shouldn't be using encryption and decryption in the first place. Because they're reversible. And if they're reversible then it means an attacker could ultimately find out what the original passwords are.

You need hashing. It's not reversible, so even if someone recovers the passwords they "won't" be able to get the original passwords. Hashing is much, much more effective when you use salting (check Wikipedia). PHP's password_hash() and password_verify() take care of all that for you so all you need to do is learn how to use them.

[StevenOliver]

benanamen - yes you're right, I'm trying to learn the code like the rest of us..... but there is a concept I still cannot grasp. I just finished experimenting with code that goes like this:

$encrypted = openssl_encrypt(
  "SECRET MESSAGE", 'aes-256-cbc', "$salt:$password", null, $iv
);
$_INSERT_IN_MYSQL = "$salt:$iv:$encrypted";

... and then when you retrieve it later you explode the 'colons' to these components
$salt          = $components[0];
$iv            = $components[1];
$encrypted_msg = $components[2];

... and then once again, you have the "salt" to decrypt it!

What am I missing!? I must be missing something.

It's like locking your car door but leaving the key next to the lock.

Hacker sees this:
ouwuuwuweuouwweoue : ououowueouowuoweruowe

And hacker knows one is the 'salt' and the other is the secret message.

What am I missing?

[requinix]

You aren't missing anything. It's a stupid scheme. And that's why nobody does it.

[StevenOliver]

requinix, thank you, but would you please allow me to clarify a bit more:

I read where someone says to use AES_ENCRYPT for mySQL.

So I create a webpage called "user_form.php" and my code goes like ths

$birthdate = $_POST["visitors_birthdate"];

$salt = 'mySpecialWord';

// and use this query to insert into mySQL:
insert into myTable (users_birthdate) values (AES_ENCRYPT($birthdate,$salt));

.... and 'voila' the mySQL table now looks all encrypted!

However, that evening unbeknownst to me, a hacker breaks into my hosting company's server and sees the encrypted data in that mySQL table. Since the hacker is already in my user directory, all they have to do is view the PHP page I created where it says "$salt = 'mySpecialWord'" and then they just run the following code:

select aes_decrypt(users_birthdate,$salt) from myTable;

See what I mean?

I have read page after page of fancy encryption schemes, they all use fancy "$salt" but the thing is, that "$salt" variable is declared right there on the doggone page that's inserting the data into the table -- all the hacker has to do is look at the page?

There must be something I am missing, or some way the pros "hide" the $salt.

I did finally understand about hashing -- where nobody (not even the website owner) ever sees the "$salt" but you can verify if the 'message' or 'password' is correct or not. But you can't decrypt anything that's been encrypted.

But I can't figure out the basic concept of encrypting and decrypting. 

[requinix]

If someone breaks into your server and sees all your code then they can see everything. Obviously. You seem to think that encryption solves all the problems. It doesn't.

Google. Please. Google around for answers to your questions so we don't have to explain them. The internet does a good job of explaining what encryption and hashing and salts are all about.

[ginerjm]

You encrypt a birthdate.   (Why?)  And then a hacker sees your encrypted data.   But then he also sees your code?   How is one connected to the other?  Methinks you are trying to learn how to secure your DATA and confusing that with something entirely un-related.  Slow down and take the first advice that was presented here to properly store your data into the database and stop worrying (for the moment) about your code being secure.  For one thing - you might keep your more sensitive PHP scripts in a folder that is not in your root tree so that normal hacking to view that portion of your domain will not get to them.

[gizmola]

A salt has 2 purposes.  In both cases, they assume that an attacker got access to your data, but not your code.  As already explained, this happens all too often due to SQL injections and coding errors.  

If your server is fully compromised it doesn't really matter what you did to encrypt your data, which seems to be a concept you are stuck on.  

When used with a hash, a salt is added so that a Rainbow table would not be effective.  

Keep in mind that you can not decrypt a hash.  All you can do is provide input, hash the input, and see what hash is produced.  For passwords, you compare the computed hash to the stored hash, and grant access when they match for a specific user name.

So one way to try and reverse engineer a hash, is to create a database of inputs and hash values.  This can be very effective because so many people use poor passwords (names, common words, simple phrases).

A salt adds some noise to the raw input that changes it sufficiently to defeat a rainbow table.  A best practice is to provide a different salt for each hash, which then makes Rainbow generation, even with salts, a very tiresome activity.  If they know a global salt, they can generate a Rainbow table with that salt.  If however, you have a salt for each row/hash, they have to create Rainbow tables for any/all rows, and that is going to be time consuming.

Some values are not appropriate for hashing because the application requires the ability to access the original value.  Your AES_ENCRYPT example is one such scenario.   You typically see this used with privacy values like social security numbers, pins that you have to disclose to a customer service rep, or credit card numbers. 

In the case of AES_ENCRYPT, that is not a "salt" per se, but rather, a passphrase or key.  You can hash a value without using a salt, but you can't encrypt a value without a key.  That is how they differ.

I will say that when people use the mysql AES_DECRYPT() function call, it is often with a single key/salt value purely for pragmatic reasons, as an individual key used on a per row basis would mean that you could never do a query against the entire column  ie.  SELECT * FROM TABLE WHERE AES_DECRYPT(SSN, $key).

Hope this helps you understand these concepts a bit better.  

[StevenOliver]

 

Gizmola: "...seems to be a concept you are stuck on." Yes, I think you are right -- I have this concept of a "hacker breaking in" and then they see the Encrypted Data, but they also see that "salt" key right there also!

Good point. And, further, if the hacker truly "broke in" to the server, they will be able to "listen in" on any and all new data inserted.

Requinix: thank you. The reason I'm here is because I've already spent too much time on Google :-) There are a gazillion tutorials all suggesting variations of:

$secretKey = md5('secretWord');
function encryptate($string, $secretKey) {
$passcrypt = mcrypt_encrypt(MCRYPT_RIJNDAEL_256, $mc_key, trim($string), MCRYPT_MODE_ECB);
$encoded = base64_encode($passcrypt);
return $encoded;
}

...and this:
$encrypted = openssl_encrypt( "SECRET MESSAGE", 'aes-256-cbc', "$salt:$password", null, $iv);
$_INSERT_IN_MYSQL = "$salt:$iv:$encrypted";

...and this:
$passphrase = 'mySuperNeatRandomNumber';
insert into myTable (users_birthdate) values (AES_ENCRYPT($birthdate,$passphrase));

The "best" way I should have been asking my question is this:
1.) What is one of the better methods?
2.) What are some ideas where to store that "$passphrase" (having it right there directly above the mysql insert code just seems dumb).

Thank you in advance!

[requinix]

22 minutes ago, StevenOliver said:

Requinix: thank you. The reason I'm here is because I've already spent too much time on Google ? There are a gazillion tutorials all suggesting variations of:

I mean you should stop looking for code and instead learn the underpinnings of what all this is supposed to mean and accomplish from a higher level. Coding tutorials generally don't go into much explanation about stuff like what salt and pepper mean. And that's what you're missing out on. So forget PHP and MySQL and anything else directly related to the code you have to write and focus more on understanding the principles.

Thus,
1. The correct method for passwords is to use salting and hashing. Anything less, including using encryption, is wrong.
2. Salting and hashing is a solved problem. You can tackle this question once you've grasped the principles. Spoiler: we've already answered this at least twice in this thread.

[benanamen]

1 hour ago, StevenOliver said:

The "best" way I should have been asking my question is this:

I am going to jump back in here. You learned something very important when posting to forums and that is, asking how to solve your problem, not how to solve your attempted solution. Your OP (Original Post) is known as an XY Problem. The description is in my signature. I will also refer you to this page on "How to ask Questions the Smart Way". It provides a lot of helpful detailed info.

[kicken]

3 hours ago, StevenOliver said:

 

2.) What are some ideas where to store that "$passphrase" (having it right there directly above the mysql insert code just seems dumb). 

You have to store it somewhere if you want to be able to encrypt/decrypt your data.  Just make sure that somewhere isn't a place people could access easily.  Inside your code as a constant/variable is fine.  As mentioned, it's far more common that someone gets the data from your database but not your code.  If someone is able to access your code, then they could likely do more than just read your key which is bad.

However, one way to help guard against someone getting access to your files as well is to only store your key in memory.  How this works is you store the key in some password-protected ecrypted format on disk.  When your server/application is first booted up then someone would have to enter the correct password to decrypt the key and load it into memory.  It's still possible for an attacker to obtain your key this way, but it increases the difficulty more.  The down side of this is that if your server ever crashes / reboots your application will not work until someone enters the password for the key.