0

I am creating website with login. I have salted hash of password, my question is - Is it better to create hash in php, or is it better to create it within sql query?

SQL

INSERT INTO users (USER, PASS) VALUES ("foo",SHA1( CONCAT(  "salt", MD5( 123456 ) ) ) )

PHP

$pass = sha1( "salt" . md5( 123456 ) );
$link->query("INSERT INTO users (USER, PASS) VALUES ("foo","$pass");

And its not only about creating user, it could be checking when signing in.

The thing is, I've heard that everything that happens in database is quicker than in php, but I am afraid to send sql with clearly visible password (security reasons).

Improve this question
6
  • 2
    Security is hard. Do not re-invent the wheel. You should use an existing, proven authentication system. Commented Feb 19, 2014 at 16:26
  • For example, your salt is useless, and your hash is too fast. Commented Feb 19, 2014 at 16:26
  • see: php.net/manual/en/faq.passwords.php Commented Feb 19, 2014 at 16:28
  • @SLaks 'Salt' as a salt was just an example, what do you mean by hash being too fast? Commented Feb 19, 2014 at 16:30
  • 1
    @Kudlas - Check this question for a good explanation: stackoverflow.com/questions/12804551/… Commented Feb 19, 2014 at 16:31

4 Answers 4

Reset to default
1

Technically you can quite securely pass unencrypted passwords from the application to the database server, even if they're on different machines - it's all TCP/IP and can therefore be encrypted if required ... however, why would you? The overhead for generating your hash in the application is minimal (it can even be more efficient depending on what you're doing) and it provides far greater flexibility and ease of use.

Instead of creating a "roll your own" solution you've got access to pre-existing libraries/function within PHP itself, such as Hash which allows you to select the algorithm you want to use.

If you really feel the need to get full-on tinfoil hat you could encrypt the information in the database as well with AES_ENCRYPT although not anything you actually want to search or index on.

Improve this answer
Sign up to request clarification or add additional context in comments.

Comments

0

You should hash the password as early as is feasible. Definitely do it in PHP, not SQL.

You should not use md5 to hash passwords. It is outdated and insecure. Here is a reference on modern secure password storage: https://crackstation.net/hashing-security.htm#properhashing

Improve this answer

Comments

0

You listed a valid security concern, so go ahead and handle it on the PHP side. Unless you're handling a very large amount of traffic you don't need to worry about the tiny performance difference between the two.

Improve this answer

Comments

0

I've heard that everything that happens in database is quicker than in php

No. Usually bulk operations (i.e. operations affecting multiple rows) are much faster in a rlational database. However webservers and application servers (i.e. PHP) are easy to scale horizontally. But databases don't scale well - hence even though it's often far from 'efficient' performing bulk operations at the application tier is a more scalable solution (facebook sort their query results in PHP rather than on the database).

So, in short, which is better depends on issues you've not addressed in your question.

If you absolutely need the fastest solution then you should measure it yourself

BTW generating a hash of a hash is just burning CPU cycles - 

SHA1( CONCAT(  'salt', MD5( 123456 ) ) )

is no more secure than

SHA1( CONCAT(  'salt', '123456') )

Update

One consideration did occur to me: doing the encryption in the database potentially widens the attack surface (e.g. plain text password potentialy appearing in logs).

Improve this answer

7 Comments

Wrong; burning CPU cycles is good. You want to force dictionary attackers to spend as much time as possible on each attempt.
No - forcing attackers to burn CPU cycles is good - but there is no difference in the number of cycles they need to burn between the 2 methods.
No; MD5ing the password first forces them to burn more cycles. It's the completely wrong way to do it, but it does help a bit.
@Slaks: the attacker only needs to generate the Md5 hash if they ALREADY KNOW THE PASSWORD AND THE SALT and want to find the hashed value. If you don't believe me, that hashing twice is a waste of time, go over to crypto.stackexchange.com and ask them if applying more than one hash function to a value results in something which is more secure / less secure / just as secure as applying a single hash function.
I'm not saying it's more secure; I'm saying that it makes brute-forcing slightly slower, since the attacker now needs to calculate two hashes for each plaintext.
|

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.