How to estimate the time for a hacker to crack a strong password

Question

Some kind-heart hacker just sql-injected our website, getting the hash of admin password of 10 lower case chars. It took him half a day to crack it without knowing the SALT (he know that we use "sha256" because the site is opensource).

Now, the manager is not happy. Obviously we will have to change the algorithm to something unpredictable, and a strong admin password, apart from patching that sql-inject hole.

Points to consider:

• Password are strong like : "MyB0y6thJan@)!%" : my boy 6th Jan 2015 -> easier to remember. Or passphrase "we love this website so much"

• The hackers are usually pro ones, they attacked us all the time. They may have access to 10-100 strong computer.

• Hackers may think we are using sha256 as in the opensource but we will change them to something strong like bcrypt.

• we would change password every month.

Question: if they manage to sql inject and get the hash in the future, would he be able to crack it fast?

P/S : I have read many similar topic like :

Estimate the time to crack passwords using bcrypt.

How do we estimate the time taken to crack a hash using brute force techniques

But still I am so confused now, many people ( including the hacker) claim that any hash password can be cracked to its original form, just a matter of time. While many say it may take years to crack just one.

Answer 1

It's not possible to answer how long it will take to crack a password without knowing how the password is created. If you create a password based on your (or a relative's) birthday, street address, middle name, etc it is assumed to be a week password due to Kerckhoffs's principle. Since you don't know if an attacker will know this information, it's best to assume that they will, and that they know the format you decided to use.

For the sake of demonstration, let's assume they don't know anything about your family, but they know you've formatted your password as My[B0y or G1rl][day of month with suffix][abbreviated month][symbols on keyboard corresponding to year]. That's 2 possibilities for boy or girl, 365.25 for month and day, and let's be generous and say 50 for year. 2 * 365.25 * 50 = 36,525. That's nothing. An attacker could try hundreds of similar methods without having to do a significant number of hashes.

The only way to reliably estimate password strength is by basing the estimate on the password generation method. If your password generation method is to generate 10 random alphanumeric characters, you'll be randomly picking 1 password from a set of 62¹⁰ passwords. On average, an attacker will guess your password after trying half of the possible passwords, so unless they get extremely lucky they'll have to guess around 62¹⁰/2 = 419649682934170112 times before they guess yours (of course this could be higher or lower if they're lucky).

This 8x GTX 1080 benchmark has been floating around for a while, if we assume that's what an attacker uses, they can do 200 billion md5 hashes or 826 bcrypt* hashes per second. If you're worried they have a room full of ASICs, take that times a billion (although bcrypt is somewhat resistant to ASICs). Worst case scenario with bcrypt is 62¹⁰ / 2 / 826000000000 = 508050 seconds, which is only a few days, but as far as I know bcrypt ASICs are still unlikely to exist (or be that fast if they do exist). Of course, you could easily make this much better by using 12 or 15 random characters instead of 10.

_{*Assuming a cost of 12; the benchmark gives 105.7 kH/s with cost 5, so 105700/2^(12-5) ≈ 826 H/s.}

Answer 2

The short answer is that there is no answer and the length of time to crack a password is directly proportionate to 1) length and 2) complexity. This is straight from the SANS org:

Strong passwords are long, the more characters you have the stronger the password. We recommend a minimum of 14 characters in your password. In addition, we highly encourage the use of passphrases, passwords made up of multiple words. Examples include “It’s time for vacation” or “block-curious-sunny-leaves”. Passphrases are both easy to remember and type, yet meet the strength requirements.

If you have a complex and long password (e.g. 16+ characters, it can take years to crack. However, even a long password is susceptible to cracking IF you use dictionary words, or use a word and re-arrange the letters with numbers or symbols (e.g. P@$$w0rd is not a good password, even though it includes numbers, capital letters, and symbols).

I would encourage you to use a random password generator like this one.

Finally, passwords themselves are not sufficient to protecting one's site or infrastructure. Consider performing regular pen tests, scans, vulnerability assessments, and tools like fail2ban. SQL injections are relatively easy to protect against by sanitizing input but does require time to understand the vulnerabilities first. If you simply secure your password, someone can still use pass-the-hash or some other exploit to hack your site. Security is a layered approach, so focusing on a specific security failure is not a wise approach.

Answer 3

While other answers here are addressing the question asked, I get the impression that the OP is not really addressing the problem. So this is really a comment rather than an answer.

getting the hash of admin password...without knowing the SALT

This rather implies that the salt is held independently of the hash - which suggests that the salt is not randomly generated and unique for each account. That's not good.

just sql-injected our website

While I presume that you are already looking to prevent the SQL injection vulnerabilities, this also implies that the application has direct access to the tables containing authentication information. Erk! Even if you fix the known SQLI vulnerabilities, the application's access to this data should be mediated via SQL procedures with privilege separation.

Obviously we will have to change the algorithm to something unpredictable

No.

Firstly, the sha256 is only part of the algorithm you use to validate passwords. There are a lot of other things to consider here. Simply replacing sha256 with something which is computationally more expensive won't fix an issue elsewhere in your password validation.

I would encourage you to consider the larger picture.

In his answer, SomeGuy suggests using a large, random password. While this will address brute forcing of the hash, it still doesn't help if you've made a mistake elsewhere. It also means that people are more likely to make a record of the password somewhere. Hopefully they do that in a proper password manager rather than on a post-it note, but even the former are not necessarily 100% reliable. You've increased the attack surface.

we would change password every month.

Both NIST and GCHQ have been challenging this received wisdom relatively recently. It certainly wouldn't have provided any protection against the attack you describe. As per the discussion on password complexity, the more frequently you change a password, the more likely it will get communicated and written down.

Given that you can change the code of the application and its open source, I would recommend:

• you take a long look at the code round about the call to sha256() - make sure you are using a password stretching function

• you use unique, randomly generated salts for each account

• you implement two-factor authentication (with a facility to enable this based on privilege or user preference)

• you consider privilege isolation of the password hash data