13

Please read the updates too since my "actual confusion" is in there.

It has been quiet sometime, since Joomla! started supporting the bcrypt hashing algorithm, alongside the md5 + salt that has been the defacto since Joomla! 1.5.

Now my question is "As an end user, what benefits do I get if I start using Bcrypt right away, In comparison to the current algorithm viz. MD5 + salt? Does it even make any difference for a normal blog with a few hundred visitors daily?"

Update:-

Also I read somewhere that due to the speed of md5 hashing, My password could be easily calculated in a matter of days/months @ most.

But does this not require my hash to already be present with the attacker to compare to? And If he/she doesn't have the hash in the first place, then how does the hashing algorithm that I use, affect my sites security? And eventually he ends up having to Brute Force my login page anyways?

And if its down to Brute Forcing their way through, then isn't Bcrypt equally vulnerable to password guessing?

E_net4
  • 27,810
  • 13
  • 101
  • 139
Mohd Abdul Mujib
  • 13,071
  • 8
  • 64
  • 88
  • 3
    Because, any way you slice it or dice it, MD5 is still MD5. It's time to step into the *21st century* ;-) – Funk Forty Niner Jan 15 '16 at 14:44
  • 1
    http://security.stackexchange.com/questions/61489/is-salted-md5-or-salted-sha-considered-secure --- http://security.stackexchange.com/questions/19906/is-md5-considered-insecure --- https://crackstation.net/hashing-security.htm – Funk Forty Niner Jan 15 '16 at 14:46
  • Thanks for answering, Please read the update(My real confusion). – Mohd Abdul Mujib Jan 15 '16 at 14:49
  • 2
    If they don't have the hash in the first place you wouldn't need to hash at all. If noone was looking at your database plain text would be fine, but you do it especially for the case when someone does know the hash. – dryman Jan 15 '16 at 14:52
  • You're welcome. I'm pretty sure you can get some answers in the links I've left you up there. – Funk Forty Niner Jan 15 '16 at 14:53
  • 1
    You really shouldn't use [MD5 password hashes](http://security.stackexchange.com/questions/19906/is-md5-considered-insecure) and you really should use PHP's [built-in functions](http://jayblanchard.net/proper_password_hashing_with_PHP.html) to handle password security. If you're using a PHP version less than 5.5 you can use the `password_hash()` [compatibility pack](https://github.com/ircmaxell/password_compat). – Jay Blanchard Jan 19 '16 at 13:33
  • Yes, offline attacks do require the hash to be present. I'm sure all companies successfully protect passwords, like [ebay](http://www.pcworld.com/article/2453400/the-biggest-data-breaches-of-2014-so-far.html) did, and like [Anthem](http://www.crn.com/slide-shows/security/300077563/the-10-biggest-data-breaches-of-2015-so-far.htm/pgno/0/9) protected health care data, and the [U.S. Office of Personnel Management](http://www.networkworld.com/article/3011103/security/biggest-data-breaches-of-2015.html) protected data and over five million fingerprints that could be used for authentication. – Anti-weakpasswords Feb 24 '16 at 04:02

3 Answers3

7

But does this not require my hash to already be present with the attacker to compare to? And If he/she doesn't have the hash in the first place, then how does the hashing algorithm that I use, affect my sites security? And eventually he ends up having to Brute Force my login page anyways?

First, no. Many sites allow login attempts without a rate limit. With MD5, assuming the servers can handle it, a user could very rapidly attempt to brute-force passwords just by trying lots of passwords in quick succession. bcrypt's slowness guarantees that such an attempt will be much slower.

Second, a key security concept in computing is defense in depth. You don't want just one level of security - it's fairly easy to accidentally write a SQL injection vulnerability that might let an attacker dump password hashes. By using bcrypt, you limit the damage such a vulnerability can cause.

ceejayoz
  • 176,543
  • 40
  • 303
  • 368
  • So, you are saying that, Bcrypt benefits me only 1. if my site is already compromised and all the hashed passwords leaked 2. By slowing down the brute force by slowing down the authentication process as a whole, for the attacker and the genuine user alike. – Mohd Abdul Mujib Jan 15 '16 at 15:07
  • I'd like to add, the "defense depth" that you mention is totally irrelevant in this specific question, since that "depth" can also be used with `md5 + salt` which I am already using, TBH. Sorry if I come out as condescending, but this is my genuine doubt? – Mohd Abdul Mujib Jan 15 '16 at 15:11
  • @MohdAbdulMujib MD5 + salt is not defense in depth. You can generate a brand-new rainbow table for a particular MD5+salt in a few hours with a cluster of AWS GPU instances for a couple hundred bucks at most. http://blog.ircmaxell.com/2011/08/rainbow-table-is-dead.html – ceejayoz Jan 15 '16 at 15:16
  • @MohdAbdulMujib "if my site is already compromised and all the hashed passwords leaked" Your site could be compromised in the future. Major corporations with good coding and security practices have found themselves the victims of SQL injections. **Don't assume you're the first perfect programmer in history.** – ceejayoz Jan 15 '16 at 15:18
  • "slowing down the brute force by slowing down the authentication process as a whole, for the attacker and the genuine user alike" It slows the login process for the genuine user by about a tenth of a second, and they only have to login once per session. Don't invent spurious concerns. – ceejayoz Jan 15 '16 at 15:19
  • Ok, 1. when I say that I am already using the defense in depth, I meant the plugins that prevent the exact above mentioned type of behaviors >> ip blocked after few failed attempts. or requiring a captcha after a few failed attempts. 2. If the attacker is able to dump my hashed passwords then he will most likely be able to dump my whole database. 3. I understand about "the attacker not changing password and keeping the admin pass unchanged to prevent suspicion" method of attack, and I understand the bcrypt helps "more" in this case. – Mohd Abdul Mujib Jan 15 '16 at 15:21
  • @MohdAbdulMujib Short version of what I'm trying to say: **It is the unanimous agreement of web security experts that MD5 is a horribly insecure way to hash a password. Do not use it for that.** – ceejayoz Jan 15 '16 at 15:24
  • 1
    "If the attacker is able to dump my hashed passwords then he will most likely be able to dump my whole database" Yes, but potentially read-only. Having those passwords be MD5 means they can convert that read-only access into a valid login for an administrator account, log in with it, and start deleting stuff. Also consider: users may have used the same email+password on other sites, so by storing MD5 you're risking their *other* accounts on other sites. – ceejayoz Jan 15 '16 at 15:26
  • Assume your site is compromised. Some people here are confusing MD5 and MD5+Salt (which is much less vulnerable) but it is still not as good as bcrypt. Also ... your users likely use the same password on other sites and you will have compromised their other information. Really, you don't want that. – Elin Jan 17 '16 at 18:13
  • Security through slowness really bugs me. What is slow today is not tomorrow. And it seems a huge kludge compared to using a decent algorithm and even better getting rid of something as archaic as password based authentication in the first place. – Samantha Atkins Jan 14 '22 at 23:56
6

From what I understand Bcrypt is safer. It's made to be slower, this makes it harder for an attacker to brute-force a password. It can be configured to iterate more and more which is useful since CPU's are getting more powerful.

That's the point of having configurable slowness: you can make the function as slow as you wish. Or, more accurately, as slow as you can tolerate: indeed, a slow function is slow for everybody, attacker and defender alike.

These links might be of some help:

https://security.stackexchange.com/questions/61385/the-brute-force-resistence-of-bcrypt-versus-md5-for-password-hashing

https://www.bentasker.co.uk/blog/security/201-why-you-should-be-asking-how-your-passwords-are-stored

What's the difference between bcrypt and hashing multiple times?

https://www.quora.com/What-is-the-difference-between-bcrypt-and-general-hashing-functions-like-MD5

https://security.stackexchange.com/questions/4781/do-any-security-experts-recommend-bcrypt-for-password-storage/6415#6415

Community
  • 1
  • 1
Mosh
  • 461
  • 5
  • 20
  • Thanks for the links, though I have already read these, but they don't explain the difference for a totally uncompromising sites passwords. – Mohd Abdul Mujib Jan 15 '16 at 15:04
  • 3
    @MohdAbdulMujib - In a "totally uncompromised site" you could store the passwords plaintext, hashing is done for the case that an attacker has read access to the database and knows the hashes (SQL-injection, discarded server, lost backup, ...). Then (s)he can brute-force with the whole speed of his local system (offline attack). With common hardware you can calculate about [100 Giga MD5 per second](http://hashcat.net/oclhashcat/#performance). – martinstoeckli Jan 15 '16 at 19:59
1

Besides a "salt", BCrypt accepts a "cost" argument - which is its main feature. Cost is the amount of computational work you want to apply to the hashing. Think of it as re-hashing the result 2^n times, where n is the cost.

The hashed string will be something like cost;hashed_string (ex. 20;5D4140). This, of course, is not the real format, but an oversimplification to show the idea.

This "cost" concept makes BCrypt "obsolescence resistant". If in 10 years the computational power increases 1,000 times you just need to re-hash your hashes with a higher "n" (no need to have the original value to increase cost).

Daniel Loureiro
  • 4,595
  • 34
  • 48