1

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.

10
  • You can't estimate simply by knowing the length. "aaaaaaaaaa" would be cracked instantly, "CEbkAnmTXs" would likely take a few months at 10 billion hashes per second. Jun 20, 2018 at 17:20
  • @AndrolGenhald : I can't estimate, that why I asked. By strong password I meant something like this "!loveMyk1ds", or maybe some generate like "CEbkAnmTXs". I am asking a legit question, why ppl downvoted me? Maybe my english is not good, let me rephrase my question. Jun 20, 2018 at 17:28
  • "unknown algorithm" is impossible to calculate the hash time, since it literally can take from > 0 to < inifinity to hash a single input. In other words, the difficulty of hashing can be arbitrarily easy, or arbitrarily difficult. Jun 20, 2018 at 17:34
  • It's not that the english is poor, it's that you can't estimate how strong a password is without a definite password generation method. "!loveMyk1ds sounds like a good password" isn't a well defined method, if you guarantee that it's generated randomly from a specific character set then estimating the strength is rather easy. Jun 20, 2018 at 17:35
  • @SteveSether : by "unknown algorithm", I JUST mean the hacker doesn't know it , he may think it is sha256 as in the original opensource , not expecting us to change it to bcrypt for example. Jun 20, 2018 at 17:39

3 Answers 3

4

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 6210 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 6210/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 6210 / 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.

2
  • But what if he has 50-100 of cracking computers, ( or in fun case, if it is the government which have hundred of computers). I am serious, that hacker just logged in to our website using admin password ( he was nice though), he even say, he will try to crack php password_hash(). I am so worried Jun 20, 2018 at 18:31
  • @PhungD.An simple! Each computer can handle 826 bcrypt hashes per second. 100 computers can compute 826*100=82,600 bcrypt hashes per second. In a month (since you would change every month), they can do 82,600*60*60*24*30=214,099,200 bcrypt hashes. If the password is random, they cannot crack it before 161 million years or something like that (with probability 50%). ----> Bcrypt(randomly generated password) is OK.
    – A. Darwin
    Jun 21, 2018 at 11:36
3

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.

11
  • Thanks for the detailed answers. I agree to all. Just to say: Our website is up running for almost 5 years, quite heavy traffic and ... attacks too. DDOS, sniffing, etc.. all kind of attacks.. But loosing admin password and username is deadly serious don't you agree? If he was bad guys, he can do all kind of bad things , even slowly take over the whole server.. right? Anyway, I love the passphrase, seems simple and secure!! Jun 20, 2018 at 18:39
  • Sure, it's a big deal. I'm not saying otherwise. If he has the admin password, CHANGE IT immediately, or yes, he can take over the whole system eventually, depending on the type of hwardware/middleware/software you're running. You can still recover it if you console in, or restore from backup if it's cloud.
    – SomeGuy
    Jun 20, 2018 at 18:47
  • Please mark the question as "answered" if this answered your question.
    – SomeGuy
    Jun 20, 2018 at 18:47
  • @GomeGuy : not yet, I am still worry. Because the hackers may have access to 10-100 strong computer. They are pro, they successfully cracked many famous systems. So could you answer the part if he/they have like 100 strong computer, would it take less than ( few days) to crack a fairly strong password with that much computing power ( assuming he manage to sql inject 1 more time) ? In the mean time, I am studying on how to be 99.999% sql-inject proof.. thanks again Jun 20, 2018 at 18:59
  • It's impossible to say how long it would take and guess at what resources are at his disposal. It completely depends on how strong your password is.
    – SomeGuy
    Jun 20, 2018 at 19:11
2

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

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .