I'm trying to use AES encryption (AES_ENCRYPT in MySQL) for user passwords but I came up with a bunch of different problems.
This is the SQL query that I use to store a new user into the database:
INSERT INTO user VALUES (
'15',
'John',
'Doe',
'123 Fake St.',
AES_ENCRYPT('mypassword', 'mysalt'),
'mysalt'
)
Where the salt would be a random string in a real case.
It works fine. I mean, I'm able to retrieve the original password. In this example, AES_DECRYPT(user.password, 'mysalt') WHERE user.id = 15 retrieves mypassword. But I might be overlooking some things.
Is it secure to save the salt along with the password? Aside from security through obscurity thing.
What is the best format to store the hashed password? I'm using
VARBINARY but the stored string looks like 8�p�����_�Z�\.
And finally, how long should the password be and how long should the
salt be?
Thanks
Typically, there is no actual need to reverse encrypt a password. Having that ability inherently decreases the security of the system. Instead, use an irreversible hash function. I suggest SHA-256 (or larger) which produces a string result:
SHA2 (CONCAT (user.name, user.password, 'some salt', user.id), 256)
I have also frustrated bulk rainbow tables from being any use by rolling in other data always known at password validation time.
SHA2 requires MySQL 5.5 or later. If you are using an earlier version, SHA1() is nearly as good, and generally much better than MD5, AES, etc.
Please consider using a password hash instead of a cryptographic hash. The goals are different. See https://security.stackexchange.com/a/6415/25424 for more info. Password frameworks like what are mentioned on https://stackoverflow.com/a/6337021/516813 take care of a lot of details for you like the salting.
You should not just encrypt the password in database, but store a presentation of the password in the database.
See this question for lengthy explanation.
Related
MySQL
ENCODE('pass','salt')
What kind of cryptography is used?
Very similar to DES
Is it brute force to go salt when the password is known?
The source for the algorithm used by ENCODE() and DECODE() is available here:
https://github.com/mysql/mysql-server/blob/5.7/sql/sql_crypt.cc
Comments in that file say that this algorithm "should be ok for short strings" but that doesn't give me confidence that it is a professional-strength encryption algorithm.
Note that these two functions have been deprecated in MySQL 5.7. You should use AES_ENCRYPT() & AES_DECRYPT() instead.
However, there is also a recommendation to avoid using encryption functions in SQL at all, because if you do, the plaintext string is going to be added to your query logs or binary logs:
INSERT INTO SuperSecureTable
SET secret = AES_ENCRYPT('no one should see this', 'secret');
Re comment from #ikegami:
I think you're confusing encryption with hashing.
Correction: I take your point. Depending on how secure the requirements for the encryption, AES_ENCRYPT() is not appropriate either. It's better to use the state of the art encryption in one's application, and insert the resulting encrypted data into the database.
This would also address the problem I mentioned above, of plaintext being recorded in logs.
Okay, I have an extremely basic knowledge on how to make a secure, login system.
If you try to login, you get the attempted password, hash it to example md5, try to match the hashed password with the password stored on some sort of database/server (also hashed).
When registering it stores the md5 hash on the server, but NOT the original. So even if it's breached it's untraceable. (Even though there are services that have a database of hashes, and can attempt to reverse).
My problem is: How to store the hash? If i used a mysql database, it would have the details hard coded inside, and I don't code in php so can't really make an online one.
How would I hide the mysql credentials in my software?
Don't generate your own salts.
Research PHP password_hash and password_verify functions, which do pretty much all you ask, automatically and fairly securely in PHP 5.5+.
http://php.net/manual/en/function.password-hash.php
Also
http://php.net/manual/en/faq.passwords.php
You can also use this on PHP 5.3 with a good fix made by IRCMaxwell. Here: https://github.com/ircmaxell/password_compat
MD5 has been severely compromised and there are various rainbow tables and collision functions that can find out what an MD5 hash string originally was (down to a handful of options, which are peanuts to compute). Do Not use MD5 for hashing private data.
"How to store the hash"
By Storing the hash I think you mean that you want to store the:
$hash = md5($password_plaintext');
if this is so, then you can store this in a MySQL VARCHAR field, on the record, typically people submit login info with a username password so the username is used for the MySQL engine to find the row, and then the password hashes are compared to see if they match.
Using password_hash(), you would look up the username, then retrieve the associated password hash field value (just that value), and then compare the hash with the plaintext password from the form with:
if(password_verify($posted_login_password_plaintext, $hashfromDatabase)){
//if TRUEPassword matches.
}
That's all you need. You do not need and actually should not store any salts for hashing with.
I have a PHP file which allows users to insert text into the MySql database. I want that data to be encrypted. (Any encryption would be ok for me... MD5, SHA1, SHA512, any of them) And when the user requests the data from the database, it is shown as regular plain text (The value entered by him). Please help me how can I do it?
MD5, SHA1 and SHA512 are hash-functions, no reversible encryption.
I would recommend to use the encryption/decryption pair AES_ENCRYPT and AES_DECRYPT.
MD5, SHA1, SHA512 are hashing and compression tools, so it is impossible to decrypt text that is cloaked by these algorithms (check the difference between hashing and encryption).
These 2 PHP functions could suit your needs for this specific case: you case use this function to encrypt and this one to decrypt
On user registration, concatenate login name and password chosen by him/her with a salt value, hash the concatenation with PHP $PwdHash=md5($salt.$loginname.$password); and store $PwdHash in database.
When the user wants to autenticate later, he/she sends the $loginname and $password again.
Repeat the same with obtained credentials $PwdHash=md5($salt.$loginname.$password); and compare computed $PwdHash with PwdHash stored in your database row corresponding to $loginname.
Salt is an arbitrary constant secret value chosen by you, e.g. $salt="user3668837"; . Using the salt prevents the attacker to dig out passwords from your database with rainbow tables if he managed to steal database content.
I have a bunch of hashed passwords pbkdf2_sha256$10000$0POUvc6y8M4z$QyldL9qyQO.... Is it possible to verify them in SQL queries? Don't ask why.
Usually database systems do not support this kind of hash functions on their own. It would be difficult to write the queries anyway, because the password hashes are not searchable. To verify a password with its hash-value following steps are necessary:
Search for the row by username (cannot be done by the hash-value).
Return the password-hash from the found row.
Extract the used salt and the cost factor from the stored password-hash.
Build a new hash-value from the entered password with the same salt and cost factor.
Compare the stored hash-value and the new calculated one.
That means, you first have to know the stored hash-value, before you can verify the entered password with it. Such a hash function is surely better placed in the development language, than in the database, especially when you later have to switch the algorithm or the cost factor and need backwards compatibility.
I have a mySQL database and I am using phpMyAdmin to access it. The database has table employees with fields like name, address, email and password.
Initially the password field was just VARCHAR (20). But now I want to hash my password with SHA-256 hashing technique.
I do not have much experience with databases so I want to know is -
can I hash all my current employees passwords without affecting the other fields or the entire table?
In future when I am entering data in the database (from a web application), where do I write the hashing function to hash the password? i.e. does the hashing occurs at the front end and then the hashed password is stored in the DB or the password goes to the DB where it is hashed and then stored.
Solution and Suggestions are appreciated.
Q1: Can I hash all my current employees passwords without affecting the other fields or the entire table?
A: Yes. But you need to alter the size of your column of the password by 40-42. You will use the PASSWORD( ) built-in function to encrypt your password
ALTER TABLE tableName MODIFY `password` VARCHAR(42);
after that you can now update the password column
UPDATE tablename
SET `password` = PASSWORD(`password`);
ex.)
abcde12345 => *20B30AFAF441808B50273EDA287132EC25B02DE2
Q2: In future when I am entering data in the database (from a web application), where do I write the hashing function to hash the password?
A: In your INSERT query
INSERT INTO tableName (name, address, email, password)
VALUES ('aa','bb',''cc,PASSWORD('abcde12345'))
when you want to search for the password, encrypt first the text:
SELECT *
FROM tableName
WHERE `password` = PASSWORD('abcde12345')
one more thing, don't forget to escape your Password column with backtick since it is a MySQL Reserved Word.
You can hash the password in php and then store it in the DB:
$pwd = hash('sha256',$_POST['password']);
MySQL does not support sha256 function so you need to hash by code and then store/update your password table. Otherwise you can consider this http://stuge.se/mysql-sha256/
can I hash all my current employees passwords without affecting the
other fields or the entire table?
Yes. For example, if you’re going to use the SHA-1 hashing function, you can add the corresponding column and hash all your passwords with one query:
alter table employee add column password_hash varchar(40);
update employee set password_hash = sha1(password);
It is assumed that your plain text password column is called “password”. You can drop the original column after you have the hashes, of course (and, most likely, this is exactly what you want to do next).
However, I strongly advice you to read more on hashing algorithms and pick something better. For example, you may want to use a different hashing function and/or add salt.
In future when I am entering data in the database (from a web
application), where do I write the hashing function to hash the
password? i.e. does the hashing occurs at the front end and then the
hashed password is stored in the DB or the password goes to the DB
where it is hashed and then stored.
Most commonly, the hashing occurs on the server side each time a user logs in. Then an authentication session is created and the session ID is stored in the user’s cookies (so you never store the password or it’s hash on the client side, however, you transmit it to the server when the user logs in, and this is why it is good to use SSL at least for authentication).
In some cases, you may want to even build a separate authentication backend which only accepts password hashing requests (so even if someone cracks into your system, the exact hashing schema would be still secret until they crack the hashing backend as well, which can be a lot harder if it’s built carefully enough). However, you would only need something like this in case you really care a lot about the security and it is really important. Otherwise the typical server side hashing will be enough.