# Is a randomly generated 80-bit password strong enough nowadays?

Theoretical question - Say we have a randomly generated password with 80-bit entropy, stored as a single-round, unsalted SHA256 hash. For a determined attacker with current (2024) technology, what would be the cost of bruteforcing it, in terms of money and time?

Now what if it's stored with 10 rounds of SHA256? Does that make it 10 times more resistant?

Note that I'm aware of somewhat similar questions, but they are all several years old.

• How many bits of entropy should a password have to be reasonably future proof (10+ years)? is fairly recent (2021), addresses the problem of computers getting faster and is about 80 bits entropy too - so I think this should answer what you ask. Commented Feb 25 at 8:12
• Thank you. I had missed that one indeed, and it does provide great answers. What about the second part of my question, though? "Now what if it's stored with 10 rounds of SHA256? Does that make it 10 times more resistant?" Commented Feb 25 at 8:46
• 10 times SHA-256 is still very fast and would not be advisable for weak passwords. For 80 bits random though even a single round of SHA-256 without any salt is sufficient. But don't store the random password in plain, since then it is exposed if the server is compromised. Commented Feb 25 at 8:58
• Seconding Steffen's assessment - adding ten, or a hundred, or even a thousand rounds is only a slight drag on attack efficiency, vs true salting and stretching. Commented Feb 25 at 18:58

A random password with 80 bits of entropy is probably out of reach of most brute-force attackers in 2024, except those that are very well funded (e.g. cybergangs, 3-letter agencies, nation states, etc).

An attacker with ~\$2300 of ASIC hardware can do about 190 tera-hashes per second. So, the time it would take to iterate through 2^80 passwords, and hash each one would be:

``````(2^80) hashes    1 second
* -------------------- = 6362767471 seconds
190 * 10^12 hashes
``````

That's over 200 years.

Of course, a well funded attacker could devote more resources to brute-forcing the password to reduce the amount of time it would take, but this would result in greater cost for the equipment.

But, regardless of this tradeoff of equipment cost versus time, the cost for the energy to run the equipment would probably be prohibitive for most attackers. Modern ASIC hardware like the unit linked above requires ~27.5 Joules of energy per tera-hash. Converting the Joules to kilo-watt hours, and assuming a cost of \$0.12 USD per kilowatt hour - the cost for the energy to iterate through 2^80 passwords, and hash each one would be over one million dollars:

``````2^80 hashes  27.5 Joules       1 Kilowatt-hour     \$0.12 USD      \$1,108,182 USD
* -------------- * ---------------- * -------------- =
10 ^ 12 hashes    3600000 Joules     Kilowatt-hour
``````

So, it would have to be a very valuable password to justify an attacker making this much of an investment to crack it.

• Thanks for the great answer! And to further clarify, would using 10 rounds of SHA256 make the attack 10 times more expensive? Commented Feb 25 at 17:31
• Minor nuance: unfortunately (for attackers), mining ASICs cannot be repurposed to crack general hashes - the hard-coded algorithms are more specialized, and not a direct match. All that means is that the \$2300 number needs additional context - specifically, that a well-resourced attacker would need to fund the creation of such ASICs, rather than any ordinary user being able to drop \$2300 today to start attacking password hashes. Commented Feb 25 at 18:56
• Are botnets considered to be attainable only by well-funded cybergangs, TLA agencies, nation-states, etc.? If not, couldn't hashing be distributed across a botnet to significantly reduce the wall-clock duration? (And people running botnets aren't paying for energy consumption.) Commented Feb 25 at 21:39
• I'm not sure it's great question wording, but the question asks about unsalted SHA256. So in this scenario, the attacker may be able to spend the same amount of money to crack a large number of high-ish value passwords, rather than one very high value password. Commented Feb 26 at 10:51
• @jamesdlin yes that could be done in theory, but these botnets usually have little to no computational power (because the devices captured are not built for it) but rather their strength is the (comparatively) large internet bandwidth. Sending out DDOS packets is computationally cheap Commented Feb 26 at 12:13

If you’re brute forcing it without a database breach then the time depends on how often the front end lets you make a login attempt. A well-designed system will in any case lock the account after let’s say ten consecutive failed logins, and in that scenario your brute force will almost certainly fail. If you do have a database breach then of course no brute force is needed — you’ve got the password, since you specified it was stored as plaintext.

• You're right, if it's stored as plaintext the question is not very interesting - I've changed the scenario to "stored as a single-round, unsalted SHA256 hash". Commented Feb 25 at 8:36
• This answer still holds true. Because usually you obtain the password by accessing the database. In many scenarios you will not have to crack the password, if you have access to the database. Either you already have all the information you need from the database, or the hash of the password is enough to login into the application (e.g. the password is hashed in the browser to login and the hash is compared to the saved hash) Commented Feb 27 at 12:56
• @Falco: Directly storing the thing the client needs to send over the wire is an obvious design error. If you want to make sure the server never sees actual human-readable ASCII text versions of passwords, send a hash, but then have the password table on the server store a hash of that hash, right? So `sha256("password")` is the plaintext password as far as the server is concerned, and bcrypt or sha256 of that is the hashed password. (I don't doubt that many systems have the bad design you're talking about, though, in which case a user choosing a password can't do anything about it.) Commented Feb 27 at 21:09
• @PeterCordes I would not call it an "obvious" design error. There are several performance and compatibility benefits and the plain-text password never leaves the clients PC. There is of course the depicted vulnerability that an attacker with access to the best protected parts of your database can impersonate the user to your application. But arguably this attacker already has the keys to the kingdom anyways. - So there remains the defense-in-depth argument. Commented Mar 4 at 10:23
• @PeterCordes An example where such a design might be chosen is an app with a very high number of daily logins to access data. The computation cycles for hashing passwords on the server might be a relevant cost factor, while the attack surface is only access to the protected data, which an attacker with access to the database has anyways. Commented Mar 4 at 10:26

First the simple part

A lot of specialized high-performance computing resources worldwide are used for Bitcoin mining. All together they compute about 650 EH/s (different resources like ycharts or coinwarz give similar values), which is about 269/s. To brute-force an 80-bit secret they would need 280-69s = 211s = 2048s ~= 34min.

These computations consume about 4.5MWh/s (e.g. look at digiconomist: 142TWh/year ~= 4.5MWh/s). This means, that to brute-force an 80-bit secret, one would need about 9.2GWh energy. Using very cheap prices of 0.05 USD/KWh like in Saudi Arabia or Nigeria would cost about 460 000 USD. In reality, with a prices mix (see statista) it may cost even more, like 1 000 000 USD. But you would also need to pay for hardware, cooling, and personnel.

Now you can decide if there is anyone in the World who is willing to pay at least 1 000 000 USD for brute-forcing.

You don't use salt. This can make brute-forcing easier. Suppose you add salt.

Then 1 000 000 USD will be the price of a single password For every further password one would have to pay this amount of money again.

But...

These calculations may give a false feeling of security, if you don't tell us what attack vectors and risks you consider.

In reality, an attack may be much cheaper:

• If the application writes passwords to the log...
• If you keep plain passwords in memory for a relatively long time and the attacker can make memory dumps...
• If the attacker gets access to the private TLS key...
• If the network between the TLS termination point and the application is not trusted and you don't use encryption...
• If users don't keep their passwords properly...
• Obligatory xkcd. Commented Feb 25 at 21:27
• @RalphJ: To "Obligatory xkcd" - Your example is irrelevant. See the OP. It clearly says it is about 80-bits random password. Commented Feb 25 at 22:03
• The xkcd is an example of how "an attack can be much cheaper..." i.e. your final paragraph. Along with users not keeping their passwords properly and the other ways to defeat a password that's too expensive to crack, the scenario envisioned there applies. The energy costs are \$1.1M in the other post, and \$643M in your comment, or \$1B in your post. That's a big gap for estimations & 37% slower devices. Commented Feb 26 at 0:55
• It's unsalted, so 1 million USD makes a rainbow table that will crack all similar passwords. Commented Feb 28 at 17:07
• @user253751: Wrong. The idea is good, but first tell us how much memory you have to store it 😉 Commented Feb 28 at 19:02

Addressing specifically the question about repeated hashing:

Yes, hashing the password repeatedly (i.e. storing `H(H(...(H(password))...))`) will make the attack proportionally more expensive. The process of taking a password and processing it with expensive computation, to make it harder to crack is called "stretching". In modern systems, stored passwords are always stretched, and doing only 10 rounds of hashing would be unusually weak. (Stored passwords are also always salted, but this doesn't impact the difficulty of a targeted attack against a specific password; only the difficulty of less-targeted attacks.)

There is a standard for password stretching by repeated hashing, PBKDF2. It also does some other stuff that doesn't impact the computational cost of the hashing. Originally, the minimum recommended number of hashing iterations for PBKDF2 was 1000... almost 25 years ago. A modern recommendation is something like a million iterations.

More commonly these days, a different function would be used entirely, such as bcrypt or argon2. Whereas repeated hashing just uses as much CPU as possible, bcrypt and argon2 also require significant amounts of memory. Functions that use a lot of memory aim to favor CPUs (which the defenders are using) over GPUs or more special purpose hardware that an attacker might have.

All of this should be taken as general background on the topic of password storage only. There's a lot more you should know before trying to build a password storage or authentication system.

• Hashing that many times is not good. Adding passes gives a linear benefit (10 passes takes 10x as long to crack as 1 pass) but using a longer salt/key length offers exponentially better protection (10 bits takes 1024x as long to crack as 1 bit). The reason older encryption methods recommended 1000+ passes was because the algorithms were not completely random; so, lots of passes helped hide the vulnerability of poor randomness. Modern methods are much more random and typically recommend 12-64 passes. In fact, too many passes can create patterns in you encryption making it easier to crack. Commented Feb 27 at 17:00
• @Nosajimiki Can you provide some reference for what you're referring to? It goes against everything I understand to be best practice; also, you mention "encryption", but there is typically no encryption involved in the process of password storage. (The length of the salt is irrelevant to the situation where the password database containing the salts is leaked, which is typical. Obviously the length of the input to the hash is more important than the number of rounds, as you say; but the input is the user's password, and there are obvious issues with making it extremely long.) Commented Feb 28 at 0:12
• Wew... so this is a lot to cover in comments, but I'll try to keep it brief. Hashing (1-way encryption) is a type of encryption even though we often just say encryption when specifically meaning 2-way encryption. In this case, I am talking about all kinds of encryption. As for number of passes: no encryption method is 100% random, but each method is used to reach a peak distribution of values within a recommended number of passes. Commented Feb 28 at 15:22
• By keeping your number of passes close to the suggested number, you make heuristics modeling far more difficult. As for salt length, there are lots of ways to do salts that add security to a hash in different ways. The best salts are 2-part salts. 1 part is kept is a static key kept somewhere in a config file outside of your database, that way, if they get a SQL dump, they don't get the static salt too. So, if your static salt is '7dj3Hf' and your password is 'Qw3rty!', Commented Feb 28 at 15:23
• 1) The OP does not use salt. 2) The purpose of salt is to prevent usage of rainbow tables. It does not need to be secret. The only requirement - it should not be reused, or reused as little as possible. 3) In case of password hashing salt should be not secret, otherwise there will be no way to compute the hash to check the password. Commented Feb 28 at 19:09