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).

Kudlas
  • 659
  • 7
  • 24
  • 2
    Security is **hard**. Do not re-invent the wheel. You should use an existing, proven authentication system. – SLaks Feb 19 '14 at 16:26
  • For example, your salt is useless, and your hash is too fast. – SLaks Feb 19 '14 at 16:26
  • see: http://www.php.net/manual/en/faq.passwords.php – Digital Chris Feb 19 '14 at 16:28
  • @SLaks 'Salt' as a salt was just an example, what do you mean by hash being too fast? – Kudlas Feb 19 '14 at 16:30
  • 1
    @Kudlas - Check this question for a good explanation: http://stackoverflow.com/questions/12804551/im-using-md5-to-hash-passwords-when-should-i-jump-to-the-next-thing-sha-3 – Justin Niessner Feb 19 '14 at 16:31
  • @Kudlas: No; it's fundamentally useless. You need a unique salt per password. And standard hashes like SHA* & MD5 are too easy to brute-force; you need iteration or bcrypt. – SLaks Feb 19 '14 at 16:32

4 Answers4

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.

CD001
  • 8,332
  • 3
  • 24
  • 28
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

Jack
  • 2,750
  • 2
  • 27
  • 36
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.

Madbreaks
  • 19,094
  • 7
  • 58
  • 72
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).

symcbean
  • 47,736
  • 6
  • 59
  • 94
  • 1
    Wrong; burning CPU cycles is _good_. You want to force dictionary attackers to spend as much time as possible on each attempt. – SLaks Feb 19 '14 at 16:33
  • 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. – symcbean Feb 19 '14 at 16:35
  • 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 Feb 19 '14 at 16:36
  • @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. – symcbean Feb 19 '14 at 16:41
  • 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. – SLaks Feb 19 '14 at 16:44
  • I don't see that there's a difference between harder to break and more secure - but that does not change my assertion that hashing twice does not make it harder to crack. Please read my previous comment. – symcbean Feb 19 '14 at 16:46
  • I have no idea what your previous comment is saying. You cannot check an MD5 hash without computing an MD5 hash. – SLaks Feb 19 '14 at 17:09