3

I use bcrypt for password hashing everywhere in my php apps. However, there is still a choice between using bcrypt in the database or using bcrypt in php code. While I believe that using bcrypt is better than most other hashing options, is it more secure to use bcrypt via a function in the database, or via a function in php?

Community
  • 1
  • 1
Kzqai
  • 22,588
  • 25
  • 105
  • 137
  • What do you mean by better? – John V. Sep 09 '13 at 21:36
  • 2
    I think this is kinda POB. But if your database is *remote* and without SSL, then it might be better to hash first then send it. – Dave Chen Sep 09 '13 at 21:37
  • If you are hashing at the db level then there is still a chance someone could get the plain text version from the form before it gets hashed i always hash after the form has been submitted so the hash can be saved to the database. –  Sep 09 '13 at 21:39
  • What database do you know, that offers an implementation of the BCrypt hash function? – martinstoeckli Sep 10 '13 at 11:34
  • @martinstoeckli postgresql does after installing it, see link in post. I would assume that mysql must have some way as well, otherwise how did anyone ever use bcrypt for anything before it was available in php proper (like, before php 5.3?). – Kzqai Sep 10 '13 at 18:39
  • @Sephedo that sounds insecure if you're only doing it client-side, unless you're also hashing the first hash again with a slow hash. – Kzqai Sep 10 '13 at 18:40
  • @Kzqai - Unfortunately there is no such function in MySql and as far as i know, other databases like SqlServer and Oracle have no support neither. BCrypt was available in earlier PHP versions already via the `crypt()` function, but you are right that it was easy to make mistakes and that often it wasn't used because it was complicated. If you later want to be able to change the database, then i would do the hashing in the code. – martinstoeckli Sep 10 '13 at 19:29

2 Answers2

2

I would go for the second option and calculate the BCrypt hash in the PHP code.

If you place the password inside the SQL statement, there are additional possibilities it can leak. First the connection to the database must be made secure and then it could end up in log files.

If you place the hash in the SQL statement, you only have to care about a secure transfer to your application, the rest will be safe because only the hash can leak. As a bonus you do not have to care about SQL-injection and encoding/escaping issues. Another advantage is, that you are independend of the database system, you can also support databases without a BCrypt implementation (most databases do not offer a BCrypt function, or only by installing an extension).

martinstoeckli
  • 23,430
  • 6
  • 56
  • 87
1

Personally I think this could go either way:

If you say that the raw password can be sniffed from on its way to the database, the same also goes for hashes. The only security added is Security through obscurity. They don't know what hashing algorithm you are using, and when they find out, hashes can be cracked with time.

The issue is that people can sniff data from PHP to the database, not that the raw password is being sent. If you use SSL with your database, you should have no issues. (Not unless your database logs what queries has been sent, if your database does log queries, then you should hash with PHP)

An upside with database hashing would be that it's faster.

Dave Chen
  • 10,887
  • 8
  • 39
  • 67
  • Well, one problem that I've come across is that someone could always turn on query logging on a server, and then they'd get plaintext passwords. I suppose someone could always just stick some kind of log or curl in the php as well, though. php or sql errors that are badly timed can also cause the plaintext password to display in logs. The speed aspect sounds reasonable, but at the same time I'm not sure that faster matters for bcrypt. Rather, use of less cpu & memory resources is the important aspect, and I'm not sure that is as clear cut of a win for a database implementation. – Kzqai Sep 10 '13 at 18:42
  • Well, if anyone can stick anything into your PHP scripts, that really shouldn't be happening. Faster would mean faster for the PHP execution to be completed because the hash is calculated on the database instead. – Dave Chen Sep 10 '13 at 19:16
  • @DaveChen - This is in no way security through obscurity. It is the whole purpose of slow key-derivation functions, to thwart brute-force attacks. Hashing passwords is done for the case, that somebody can steal your database, so getting only a hash is ways better than getting the plain text password. Btw in most cases you can tell a BCrypt hash, just from looking at the signature. – martinstoeckli Sep 10 '13 at 20:00