I want to discuss wether good or bad idea:
I got a MySQL DB and created a common table "user" to authenticate an login.
|User|
|user_id|username|password|created_at|
I implemented a stored function and some triggers.
First of all:
ON BEFORE UPDATE
will generate a SHA256 hash and salt when password was changed.
salt is generated out witha mix of created_at, user_id and a global salt_mod which is stored in another "config-table".
So when entering 123 in "password" via normal UPDATe it will produce user-unique password and salt hashes.
Next I implemented a stored function
checkUserAuth('username', 'password')
returns: bool true or false
Ofcourse: receives PLAIN username and password, replicates same hashing logic and returns
bool "true" or "false", depends on if the credentials have been correct.
Pro:
This makes completely sync of password algorithm changes obsolete to any connected apps.
Database-account that is being used by the app can work without SELECT privileges on "username", "password" and "salt" privileges.
Even if the user-account of the database is stolen, passwords are still safe due to lacking permissions to read the FUNCTIONS source-code and the columns that store login-information. We only have an EXECUTE privilege here.
Contra:
Well if someone breaks in on the DB with root privileges, pretty much the source-code on "how to generate the hashes" is leaked (pretty much the salting formula) together with all information in one place. However its still hard to rainbow-table that due to unique hashes on created_at date and user_id in mix with global_salt.
The question to above scenario:
Is this a good approach or totally vulnerable in point of data-security?
I mean on one side, a break-in inside the database is always a problem that should never happen
On the other side, even with stolen source-code of the apps or stolen database-account by a bug in the app you cannot steal any login related data.
The root account is ofcourse excluded from being using elsewhere then on the localhost/server.
What do you think about this?
The primary weakness is that you pass the password in plaintext when you create the row, and every time you call your checkUserAuth() function.
This can be wiretapped (unless you ensure using SSL connections between app and database) and it will be written to the query log if you have the query log enabled. It's also visible in the processlist and the performance_schema statements history tables.
This is a good reason to do the hashing in the client, and send only the salted hash of the password when you create the row. When you authenticate, fetch the salted hash from the database, and validate it against user input in the client.
Related
I have a program where the users enters their username and password in 2 fields respectively. I store each password as a md5 hash in a MySQL table in two rows respectively (although I know is not very secure). Instead of hashing the password when the users enters it and then comparing it to the database, I do the following:
select * from users
where username = 'value_from_the_username_field' AND
password = 'md5(value_from_the_pass_field)'
I would like to ask is it true that the password would be visible in a plain text via the network before reaching the server and executing the query and how this could happen?(I could not understand the concept very well)
To make this safe, you absolutely have to salt the password hashes, and then this problem will solve itself, because the database can't do the hashing.
Instead you need to call a password-hash function in your development language, like password_hash() for PHP, and afterwards you insert the hash into the database.
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.
so..
I'm watching a Tutorial Video courtesy of Lynda.com on the basics of MySQL (cool Stuff),
The instructor is instructing us on setting up Root User Password via Console (which i've actually already Done).
He stated the following :
MySQL Stores it Users,Root Users and Permission for those users in a table called user, located in a datbase called mysql
Then a little lightbulb appeared above my head and i typed this in
{SHOW DATABASES;}
{USE mysql;}
{SHOW TABLES;}
{SELECT * FROM user;)
Then a bunch of stuff appeared that was obviously all the user info
so HERE'S MY QUESTION (actually 2 if i may)
1.Am i correct in assuming that if i (hypothetically) modify they "Y"'s or the "N"'s , i then effectively alter the permissions and/or access grants to those corresponding users.
LASTLY, i have set my password, and next to my name in the list, under the password column, there is a really long string of what appears to be a Hexadecimal string
Just for fun How would i convert that back so that it shows my password
(FYI I'm familiar with conversion of Binary to hex and to decimal and so on, but i'm guessing there's some sort of encryption at work here, perhaps AES or 3DES or something)
it's starts with a Star , followed by 40 Hex Characters, my password is only 12 Characters Long
so..to finish up, in doing all this, i now think i understand what the purpose of the mysql schema is in MYSQL
and needless to say i shouldn't delete it... right LOL
all input on this subject is greatly appreciated ahead of time
thanks guys
Am i correct in assuming that if i (hypothetically) modify they "Y"'s or the "N"'s , i then effectively alter the permissions and/or access grants to those corresponding users.
Yes - however the data is cached independently of the query cache - hence updating the table won't immediately give you this access - you need to reload the privileges or restart the database before the changes take effect.
How would i convert that back so that it shows my password
You can't. It's a cryptographic hash of your password. However given enough time and enough computing resource you can find a string which results in the same hash (which might be the same as the pasword) - this could then be used to log in as that user. But we're talking about millions of CPU hours here.
Yes, you can set 'Y' or 'N' in those rows, but after modifying system security tables you will have to execute FLUSH PRIVILEGES; command. I'd suggest you to use GRANT or REVOKE command instead of editing system tables directly.
No, it is not possible to decrypt MySQL user's password.
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.