Discussion: Entropy based password hashing

[robotdan]

Entropy based password hashing

Problem

Password hashing at scale is very costly when using Bcrypt, PBKDF2, etc. The reason for these algorithms is to increase the time it takes to hash a password in order to make it infeasible to brute force.

If the end goal is to keep entropy high and ensure brute force attacks are infeasible, there may be a better than to just continue to increase the algorithm complexity to crush CPUs.

Solution

Build an entropy based solution to select an algorithm and load factor to reach a desired amount of entropy to keep the algorithm complexity to a minimum.

For example, a 16-20 character password hashed with SHA-256 or SHA-512 is quite difficult to brute force even with a large bit coin rig.

https://fusionauth.io/blog/2019/02/21/save-a-cpu-ditch-bcrypt-use-sha2-instead

Additional Reading

https://blog.benpri.me/blog/2019/03/02/reactive-hashing/
https://blog.benpri.me/blog/2019/01/13/why-you-shouldnt-be-using-bcrypt-and-scrypt/

How to vote

Please give us a thumbs up or thumbs down as a reaction to help us prioritize this feature. Feel free to comment if you have a particular need or comment on how this feature should work.

[DistractionRectangle]

Overview

Due to salting + configurable slowness, the method of cracking some entries in a reasonably configured database is taking the n most common passwords and attempting to brute forcing each entry. There is a balance to be found between the server cost to validate a hash and relative cost for a given dictionary size n selected by an attacker.

Security

Reactive hashing does two things:

• Leaks information about the password length
• Increases the hashing rate for longer passwords

This allows a more targeted attempt at brute forcing a given db entry.
If we assume n is chosen as a function of cost, where cost scales as:
cost ~ n*m/h
where

• n is the n most popular passwords
• m is entries in a db
• h is the hashrate

For a fixed cost we can see n increases with any increase in h, and more importantly we have a better criterion for populating n for each partition in the reactive hashing scheme (which can be probed with chosen plaintext attack -i.e. they sign up multiple accounts with different password lengths to see how they appear in the db).

For example

So lets say we divide the database into two, passwords with length < 16 and those with length >= 16.

Brute forcing as described above doesn't really change for the first partition since the n most common passwords in general will likely all be less than 16 characters. For the second partition, we now actually have a shot at cracking a few entries since we can populate n for this partition only with the most popular passwords of length 16+ (and n for this partition can be extended due to the increased hash-rate from reactive hashing). If reactive hashing allows for more than 2 partitions, one can see how this only increases the expected number of entries cracked for a given fixed cost

One would have to dive into the data dumps of late to quantify the impact (if any) of this feature on security. It's probably marginal, but not something unworthy of consideration.

But let's throw all that out, as we can hand wave most of that off as parameter tuning. Let's look at utility.

What's the point of this feature?
To reduce cpu overhead for password validation which in turn saves money and perhaps mitigate the potential for it to be used to DDOS your servers.

Does Reactive Hashing effectively facilitate this?
The benefits of reactive hashing only come into play for the subset of users that have passwords that meet some criterion that above the minimum requirements. So really, its utility is a question of how many users actually meet said criterion. Users in general simply don't choose good passwords, opting to permute and stuff credentials to meet the minimum requirements.

TL;DR

The utility sought by this feature is only realized by just using the faster hashing scheme and changing the password requirements to match; it requires additional configuration (peppering, aka "in-memory salt modification" in the docs) in order to not introduce new weakness (however slight)

[patrickfav]

To be frank: this is a terrible idea.

Issues

Password Length != Password Quality

Password quality is not only determined by it's length. You are missing dictonary attacks and attacks wich use context info, such as account name, which also work effectively on longer passwords. For instance '1234567890qwerty' is a quite long but very low quality password (and has high entropy).

No Change in Performance

This would probably have very minor impact on performance as most users have passwords way smaller than the minimum entropy threshold for not using key stretching. See this analysis from the eHaromney password dump: only 384 of 1.2 million passwords had a length of 15 (or longer)

This is basically 'Roll your own Crypto'

Even if you are combining known hashes, you are essentially creating your own key derivation function which is never a good idea (if you are not a security/crypto researcher). My argument would be: if it would be a good idea to compromise brute force resistance on longer passwords, I guess there would be a password hash/KDF that would have that feature.

tl;dr Don't roll your own crypto

Increases Implementation Complexity

You make your clients more complex: Old user with long password, but used to have bcrypt? You want to change the password min length for SHA-256 from 16 to e.g. 20, how do you sync all your client code? How would you migrate such rule changes?

Leaks Password Information

You leak information about the password: maybe an attacker will only choose the SHA-256 hashed PW because she has more luck to find that in a pw dictonary?

CPU time is cheap, Memory is expensive

Further you are mixing CPU and memory demand of password hashing algorithms. CPU time is cheap and usually easily scalable, memory however is not. This is why bcrypt is still relevant (uses mainly CPU and only fixed amount of memory), while e.g. scrypt is not (scales CPU with memory and uses too much RAM in secure settings)

Do you really have a Problem with Performance?

Do you have any hard facts, statistics that proof that e.g. bcrypt is a significant contributer to reduced performance? Depending on your implementation I would guess that login is only done once per session (maximum couple of times per day per user). Are there other means to decrease that impact, e.g. longer sessions? Are there other means to reduce the risk of being DDOSed?

[polarathene]

https://blog.benpri.me/blog/2019/01/13/why-you-shouldnt-be-using-bcrypt-and-scrypt/

This is incredibly bad advice (ditching bcrypt/scrypt in favor of minimal SHA iterations). Using passphrases is good but the belief that length is relative to security strength is naive.

"correcthorsebatterystaple" will take about 20 minutes to exhaust 43 bits of entropy (average success rate is half of the keyspace, ie 1 bit less from the 44-bit passphrase) on a single current generation GPU. With a slow hash that can easily become >100 years, and that is less time to compute the hash than it takes for me to request a web page from the server and get a response.

Those are optimal attack times based on NVIDIA 3080 handling 7 billion SHA-256 per second and Kerckhoffs's principle.

---

If you want to offload server load, have the clients perform the hashing or a portion of it (always hash even if just SHA, the received client hash for validation without making a compromised leak of hashes usable passwords in themselves).

1Password has the benefit of providing users 128-bit keys that are part of their security policy, the app uses this to derive keys for decryption, it is not stored on the server thus any compromise even with simple passwords still have a 128-bit entropy key to crack (which requires more energy than it takes to boil all of the worlds oceans). That does pose it's own problems if the devices are lost as the service cannot recover/fix that, but additional fallbacks may be available (family/team plan) where the admin can assist with recovery.

[voidmain]

@polarathene - your math appears to be off. Entropy is a calculation based on length and pool size. In general, passwords are functions of ASCII characters as the pool size and the number of characters as the length. Then you apply a log base-2 in order to calculate entropy.

Here's a good article on password entropy for you to review:

https://generatepasswords.org/how-to-calculate-entropy/

According to the math, if you use a password like correcthorsebatterystaple which has 25 characters, the corresponding entropy using a pool size of 95 is:

log2(95^25) = 165 bits of entropy

Even using the largest GPUs in existence currently, this will require 2^30 years to brute force to a 50% probability or so (I'm rounding a lot but it doesn't matter given the numbers being so large). Even if computing power went up by orders of magnitude, it would still require millions of years to brute force a password of that length. Therefore, this password is secure using a SHA-512 hash with a single pass.

As an experiment, here is a SHA-512 hash of a password that has somewhere between 1 character and 48 characters. If anyone can reverse it and tell me the original value, I'll make it worth your while. :)

935ff37fb53d9bc30b5238e3523e9a79b68dec6209a3f7aa40f5af1fcbd6051ba319d7026b7a8b62acd2dfb8efc0ad1264209bcaa53e7dd9e9e94a7046b617d9

[polarathene]

your math appears to be off. Entropy is a calculation based on length and pool size.

My math is not off. This is the same mistake of the linked blog article I was quoting. That article references an XKCD article which very clearly states that "correcthorsebatterystaple" is 44 bits of entropy, while the author provided math of 117.5 bits (log2(26^25)).

So how did XKCD come up with 44 bits of entropy? Is the comic author wrong instead? Nope, and I mentioned why with this line:

Those are optimal attack times based on NVIDIA 3080 handling 7 billion SHA-256 per second and Kerckhoffs's principle.

Kerckhoffs's principle assesses entropy based on knowledge of how the password/passphrase was generated. So for "correcthorsebatterystaple" we have 4 words, and if they're randomly sampled from a set of 2048 words as our "alphabet" (as if it were a different language where a word is equivalent to a letter) we would have 44 bits (log2(2048^4)).

In that sense, a generator like getapassphrase.com can output two passphrases both of 44 bits of entropy like these:

• "dizzy pig keeps cute paper"
• "smiling soldier picks out orange shotgun"

Despite the difference in length and even words in this case, they are both 44 bits of entropy based on the generator rules. If you know the user you're attacking has generated a 44-bit passphrase from this site, you are able to perform an optimal attack at 7 billion guesses per second of SHA-256 and within 20-40 minutes (latter being full exhaustion of the key space), you'll have it cracked.

---

Therefore, this password is secure using a SHA-512 hash with a single pass.

It is only secure if the attacker couldn't possibly know more about your password and brute forced it in the manner you've calculated your entropy on 95^25. In general there are far better and more likely successful strategies that are used first to get any low hanging fruit (when a password hash dump has been leaked), but this differs from a targeted attack when the attacker is specifically interested in your account credentials and willing to focus all their efforts and time upon recovering that password.

If you are valuable enough to warrant that sort of attention, and your password is strong enough to withstand their computation power even when they know exactly how you generated your password... well they don't have to be that well funded to take more affordable low-tech approaches... (which while unpleasant, is often one of the only viable options). On the bright side, being immune to the majority of attackers around the world is a win.

Here's a 64-bit entropy passphrase btw, this would take about 4 years with 10 nvidia 3080 GPUs (( (((2^64) / (7e10)) / (60*60*24*365)) / 2 ) = ~ 4.178 years): "insane deer and comical boar remember rare raven in Jordan". Obviously that would take much longer without prior knowledge of how the password was generated, but the true entropy should be evaluated by if the attacker did know.

---

Even if computing power went up by orders of magnitude, it would still require millions of years to brute force a password of that length.
As an experiment, here is a SHA-512 hash of a password that has somewhere between 1 character and 48 characters. If anyone can reverse it and tell me the original value, I'll make it worth your while. :)

Relevant XKCD ;) (joking obviously)

At best one might try leverage some dictionary attacks, but assuming you've generated a password randomly with equal possibility of each character being from the pool of 95 values, that would be enough to not bother.

• 256 bits can be brute forced within 2 minutes with a computer the size of earth operating at the Bremermann limit, but there simply is not enough energy in the known universe to compute that IIRC, even with an efficient computer with each guess having an energy cost at the Landauer limit. These are considering the limits of physics and thermodynamics.
• 128 bits with the global bitcoin hashing network rate in 2017 (5 million TeraHashes(trillion)/sec) would take 156x the age of the universe (approx 13.8 billion years) to exhaust that keyspace. In 2021 the hash rate is 150M TH/sec which brings it down to 72 billion years, roughly only 5x the age of the universe now. We're quite inefficient compared to the limits of physics, but this is a good perspective to keep in mind.
• 114 bits of entropy requires enough energy to boil all of the oceans in the world.
• 64 bits... well that's quite feasible without a slowhash involved, still enough to not be low hanging fruit and likely a multi-year effort for a targeted attack, unless they're well funded (a few million could buy 1k units of the nvidia 3080 GPU, which computing SHA-512 would take about 46 days: ( (((2^64) / (2.3e12)) / (60*60*24)) / 2 )). This entropy can be had for 5 words out of a 7776 sized word list (eg: Diceware).
• Given all the above, it's enough to acknowledge that high enough entropy is expensive to attack not just in time but financially with the cost of energy and equipment. An attack has to be worth the cost of an attack like that, hence why a more.... affordable avenue would be taken instead.

If it's actually generated in a more memorable way such as words that reduces that entropy more, if we know those words are all lowercase or some other consistent pattern, if any punctuation/separator is used (space, hyphen, pascal case, etc), again we narrow that perceived entropy down closer to what Kerckhoffs's principle would evaluate the strength by.

---

One last mention for any visitors reading this.

A high entropy password as secure as it may seem cannot be re-used across services safely. There are various ways a service can be compromised and some even in 2021 that are far less reputable still store passwords in plaintext, all it takes is one of those being compromised to gain access if it can be re-used on more valuable targets.

Likewise, if you have some clever little pattern for extending the length with a shared prefix/suffix (eg a personal pepper if constant, or salt if it differs slightly), something some users feel more comfortable with when trusting a password manager to store the password without their secret portion, if one or more of those passwords are leaked from services and the plaintext is known, it is very likely that pattern becomes exposed weakening the perceived entropy and enabling an attacker to pull off a targeted attack more successfully. You'd be better off with something like LessPass (not without it's own drawbacks), or trusting the entropy of good generator from a password manager.

---

TL;DR

• My math is not off. It's accurate and aligns with the XKCD comic at 44 bits of entropy (4 words randomly selected from a set of 2048). This is respecting the strength based on Kerckhoffs's principle, a far better assessment of security.
• I lack the resources myself to attack even 64-bits of real entropy, let alone that of naively attacking an alphabet of 95 values to the power of a variable length up to 48 characters long.
• Although due to some public information about yourself, social engineering or rubber-hose cryptanalysis are likely more feasible approaches (not that I have any interest in either).

[voidmain]

Just a reminder that while we appreciate lively discussion, we also want it to be civil. We have a community code of conduct here: https://fusionauth.io/community/forum/topic/1000/code-of-conduct

Please think twice before mentioning violence, even when you are joking (I understand the context of the comment and the XKCD comment, but it may be interpreted differently by different readers).

@polarathene - please edit your comment when you have a second so that is not mentioning any type of violence.

Also, I'll be responding to the last comment at some point. It still appears to have some mixed messages and incorrect math. It will take me a bit to get to though so stay tuned.

[polarathene]

but it may be interpreted differently by different readers

Apologies, I thought given the linked content and emoji usage the context of not being serious about violence would be difficult to misinterpret (while that approach is very real, I don't endorse it obviously).

please edit your comment

I hope that's sufficient?

---

It still appears to have some mixed messages and incorrect math

I'd be glad to clarify any of that for you. I'm always open to being wrong and corrected myself, but I'm fairly confident in this math. If I have slipped up, do let me know! :)

64 bits of entropy:

• ( (((2^64) / (7e10)) / (60*60*24*365)) * 0.5 ) = ~ 4.178 years == ( (<entropy> / <hashrate>) / <seconds in a year>) * <halve time for average success rate> ) = ~ 4.178 years
  • That is, with 10 nvidia RTX 3080 GPUs each capable of SHA-256 hash rates of 7 billion per second (70 billion == 7e10), we get the total time in seconds to exhaust every permutation in the given keyspace for that entropy range.
  • On average success is assessed at iterating through half the keyspace (1-bit less of entropy), it could of course be much sooner or later but this is a common estimate to make for time expected.
  • 4 years is a bit of a long effort, but throwing more compute power into the mix helps resolve that (10 GPUs for a serious attacker is generally low). The key take away is that at this amount of entropy, the attacker is probably targeting you but you're likely to be safe from the vast majority of attackers who aren't aware of you being worth the effort or resources.
  • This entropy is calculated based on the assumption that the password generation is public knowledge (eg: the attacker knows that I used getapassphrase.com for a 64-bit entropy password, or that I used 5 randomly selected words from a 7776 word Diceware list). Otherwise by all accounts the strength and entropy calculated would be considered higher for a naive attack.
• If the service storing the password is reputable enough that they make an effort to have proper security practices, you can enjoy the difficulty to crack being much higher, possibly infeasible. Alternatively you could leverage this to lower the entropy for something more memorable like the 44-bit examples (not advisable for high value credentials).
• A decently configured slow hash can discourage parallel computation efficiency if it's designed to be memory-hard. This drastically reduces the hash rate (bcrypt with work factor of 5 can only manage ~75k/sec on that same RTX 3080 GPU. These days it's fairly standard for the work factor is tuned to 10-12, a hash rate of ~500-2,000/sec)... augmenting the 4 years attacking SHA-256 hashed passwords to 15-60 million years.
  • This augmented attack time is naive as bcrypt leverages it's 4KiB memory requirement to hamper the many cores of a GPU, each with limited local memory to force higher latency global memory access and bottleneck by saturating the memory bus.
  • FPGAs can avoid this memory bottleneck, handling bcrypt more affordably. The cost of memory remains expensive, while bcrypt cannot increase the memory requirements, alternatives like argon2id can.
  • Augmenting the attack difficulty is helpful, but a weak / low entropy password isn't going to benefit as much vs better password generation practices (such as passphrases with entropy derived from Kerckhoff's principle in mind).

FWIW, SHA-512 on the RTX 3080 is about a third of the SHA-256 hashrate slowing it down to approx 2.3 billion/sec (ie 2.3e12 from my earlier comment is 1000x 2.3e9 aka 2.3 billion), so bump that 4 years estimate to 12 years for average success rate.

I'm not sure where I've gone wrong with the math above, but perhaps the perceived approach of an attack? (eg a naive attack brute-forcing variable string length with an alphabet/dictionary of 95 values to permute through). No doubt that would take longer and be infeasible if the attacker has little information to go on, but that's not a good assumption to make in security AFAIK, especially if you value what those credentials provide access to.

---

If you were questioning the math from some of my facts, I felt I was already being too verbose in my response. Let me know if you'd like any more info on any of that.

[voidmain]

Well, it took me quite a while to finally get back to this, but I think the problem here is a misunderstanding of the core problem statement.

@polarathene is specifically talking about dictionary attacks only with a limited dictionary of 2048. This would reduce the entropy to a degree that makes the problem solvable (in a time-frame that make sense). His math is correct based solely on that premise and a weak hash such as SHA-256.

However, this is not what this discussion is about. Nor have I ever suggested that we limit this discuss to such constraints. In fact, I presented a password hash using 48 characters from a set of 100 options (Ascii), which makes the entropy much larger (336 bits if my math is correct). Just because the XKCD example uses 4 dictionary words does not mean the problem statement is limited as such. Anyone could change just one character in correcthorsebatterystaple such as corr$cthorsebatterystaple and the entropy instantly balloons. You can also repeat characters, reverse words, and many other tactics to increase entropy. And you'll never know what the rules are, so as an attacker, how could you possibly figure it out?

If we return to the original problem statement and limit our discussion to the domain presented, then the discussion is less about entropy solely and more about other aspects such as:

• How do we determine if a password should use a weaker or stronger algorithm?
• Does this make a significant difference considering most users use weak/short passwords?
• What energy and overhead is reduced by requiring fewer CPUs?
• Are there any unforeseen threat vectors (does a leak of the hash provide information that is useful)?

These questions remain in the correct domain but analyze the original problem statement to determine if it is viable.

[polarathene]

I seriously want to emphasize that as a security professional you really should take Kerckhoff's Principle into consideration when it comes to entropy.

TL;DR:

If you ignore Kerckhoff's Principle, then you consider this perfectly secure:

• zzzzzzzzzzzzzzzzzzzzzzz🎯zzzzzzzzzzzzzzzzzzzzzzzz
• Excessive length (48) + "how would they know" you used an emoji (tip: Avoid headaches, emoji in passwords is bad)

64 bits of entropy is fairly solid:

• If you need more security hash the password properly. PBKDF2 or bcrypt can be used with low iterations if resource efficiency is a concern (CPU, energy costs, etc), but you'd be better served with memory-hard bottleneck with argon2id.
• Alternatively, use a password of length 20 with random alphanumeric (62^20) sequence. That is more than enough entropy (needs more energy than is required to boil all water on earth). Just not convenient for manual input, but perfectly fine stored in a password manager.

---

Apologies, I didn't read over the entire discussion and ended up repeating a fair amount that's been said already. I've tried to manage the verbosity of this response to accommodate that.

I think this response bridges any gaps in miscommunication.

---

Part 1

You are misunderstanding what I've said, here's a response summary:

• I was not talking about dictionary attacks. I demonstrated password generation from a set of words instead of single characters. It was relevant to lower entropy due to Kerckhoff's Principle.
• I gave two examples of attack depending on entropy (44-bit 2 minutes, 64-bit 4 years). A generic dictionary attack would take much longer or fail - it's inefficient vs brute-forcing the keyspace (permutations) as per Kerckhoff's Principle.
• The math is correct when you take that into account. A single SHA-512 hash (which is not much better than SHA-256) only slightly improves strength (approx 3x longer to attack). I'm not sure why this "premise + SHA-256" is being downplayed.
• Your math for 336 bits is incorrect (log2(100^48) = 318.9), if each input of that length selected randomly (uniform distribution), you can claim almost 319 bits of entropy. Your justification for it is the attacker has not optimized for bias.
• No modifiers were discussed in 2021, you've only introduced those permutations in your 2023 response. These are still patterns, and thus reduce the entropy, look at tools like Hashcat that accommodate this.
• Without taking Kerckhoff's Principle into account, your changes to augment the entropy are meaningless. They reduce the value to the user for manual input and memory, and the naive attacker would be attacking the same way regardless (ignoring the fact your outside practical naive/generic bruteforce constraints).
• Final questions are detailed in "Full Response" section below.

Please clarify

1. These rules to balloon entropy are from a password generation scheme or manual user intervention?
2. The discussion is about being confident in entropy of a password that you can disregard protecting it with additional computation (PBKDF2, bcrypt, scrypt, argon2)?
3. Given your answers to those two questions, how do you reliably assess entropy is a safe amount where Kerckhoff's Principle cannot benefit the attacker?
4. Why do you think entropy is not reduced when the input is not uniformly random? (if you assume the attacker doesn't know any better, how do your modifiers balloon entropy when the naive attack pattern doesn't change?)

---

Full Response (click to view)

@polarathene is specifically talking about dictionary attacks only with a limited dictionary of 2048.

Incorrect.

• The "alphabet" is 2048 in size, as opposed to say a-z + A-Z + 0-9 being 62 values in an "alphabet".
• Throw in 33 more special characters (eg: !@#$%) and you get your standard 95 ASCII "alphabet".
• Instead of single characters, I referred to a set of 2048 words, a much larger set to mix from.

A dictionary attack provides combinations of those individual items from the set, usually to bias input towards more probably patterns, like common passwords ("password", "Password1!", "P@$$w0rd", "JohnDoe42", "abc123", etc).

So in this case the "limited" dictionary attack is a combination of words instead, but with proper random selection, there is no bias in patterns, so a dictionary isn't too useful vs brute force (just assume Kerckhoff's Principle).

---

This would reduce the entropy to a degree that makes the problem solvable (in a time-frame that make sense).

Entropy is calculated from the keyspace (total permutations) which you can get from the set size ("alphabet") to the power of key length (with the 2048 words, a length of 4 would be 4 words).

So no, the entropy here cannot be calculated from the input "alphabet" alone, you need to take into account length.

---

However, this is not what this discussion is about. Nor have I ever suggested that we limit this discuss to such constraints.
In fact, I presented a password hash using 48 characters from a set of 100 options (Ascii), which makes the entropy much larger (336 bits if my math is correct).

Hopefully I've cleared things up now, and you can see that the discussion remains on topic.

log2(100^48) = 318.9 (bits of entropy). Your math is off a little, but as you can see, we've already had this discussion back in 2021, and I'm basically citing back the same statements you relayed to me.

Do note that there is a ceiling depending on the hash used. For SHA-256 or SHA-512, IIRC a collision is expected to be hit in half their size, so SHA-256 would be 128-bit, anything beyond that wouldn't add more entropy if you only need to reproduce the hash, and not the original input (depends on the attack).

---

Anyone could change just one character in correcthorsebatterystaple such as corr$cthorsebatterystaple and the entropy instantly balloons.
You can also repeat characters, reverse words, and many other tactics to increase entropy. And you'll never know what the rules are, so as an attacker, how could you possibly figure it out?

I know I've brought this up to you multiple times, but you keep ignoring it... The attacker may not know, but you judge entropy by Kerckhoff's Principle as a worse case.

Otherwise by your logic how would the attacker know any better, I could just use mmmmzzzzmmmmzzzzmmmmzzz@mmmmzzzzmmmmzzzzmmmmzzzz (48 chars). Despite the patterns, is the entropy really 318.9 bits? or is it more realistically 6 bits? (mmmmzzzz or mmmmzzz@ at a length of 6, aka 2^6).

We could assume the 3 unique characters are not known from our pool of 26 lowercase letters and 1 special character, so our "alphabet" increases from just 2 "words" to mix and match to 22308 (26^2 * 33), which for a length of 6 is an entropy of 86.67 bits (log2( ((26^2) * 33)^6 )).

In that sense, you're correct, entropy increased nicely even with the very basic password generator rules. That entropy would also apply to this compact version mzmzm@mzmzmz (12 chars), but it's no longer the minimal entropy, since 78.84 bits (log2(95^12)) without the fancy generation rules is lower now.

Would it be more secure with emoji? 🎉🎉🎯🎉🎉🎉 The alphabet size is considerably larger, and the chance that the attacker would use emoji if we ignore Kerckhoff's Principle is low. In this case the mz and m@ variations have been substituted with single emoji each reducing key length to 6.

• The entropy becomes 70.96 bits (log2(3633^6)), if you knew the length and that it was only using emoji.
• The entropy isn't really possible to calculate now for the typical attack assumption of ASCII only input, as no emoji would ever be tried.
• Realistically, it's two emoji only, and only changing 1 - the entropy should be assessed as far lower and I'm sure most would agree that it's a bad idea (besides the fact that you should not use emoji in passwords because they're unreliable as input).

We've established that:

• Regardless of what the input "alphabet" is, key length alone does not equate to high entropy.
• Knowing the rules behind the targets password generation allows us to better assess the actual entropy which could be significantly lower than naively assumed.

---

How do we determine if a password should use a weaker or stronger algorithm?
Does this make a significant difference considering most users use weak/short passwords?

In both cases, if the time to process the password is minimal (500ms say) it'd barely affect the UX for the user, while significantly impacting the attacker.

For weak entropy, users should be better educated but with decent 2FA and password generation that really becomes less of a problem. There are plenty of concerns here regarding users and security that we won't discuss, we're just focused on what we can do to secure against an attack.

If weak entropy is a concern, add some in. Services like 1Password do this properly, but you also have pepper and salts. For offline attacks you have resources, where memory is an excellent bottleneck to scaling an attack. Your password KDF offsets entropy concerns, configure argon2id.

What energy and overhead is reduced by requiring fewer CPUs?
Are there any unforeseen threat vectors (does a leak of the hash provide information that is useful)?

I'm not able to answer these well. It depends.

With enough entropy in your password, you could store with a single SHA256 hash, nothing else as an attack would be infeasible (128 bits is more than enough to require energy to boil all the oceans in the world). If the attacker is motivated, they'll find another way.

If the entropy is low, you are risking energy efficiency over security. You'd need to evaluate if the savings in energy are beneficial over the increased risk from low entropy.

A leaked hash with proper practices should not leak information that is useful. You're more likely to have a threat vector elsewhere, often through the users being manipulated or careless.

---

Part 2

A quick glance over the discussion history seems it was about:

• Using a single SHA-512 hash on the password for efficiency instead of best practice, on the basis that passwords have sufficient entropy?
• A long-winded debate over entropy and how it's assessed:
  • Kerckhoff's Principle: Assume that the attacker knows your password generation strategy.
  • Naive Entropy: ASCII set of chars to the power of password length (2021: As a word sequence, 2023: Now with modifiers).
  • With 2023 modifications, it's even less clear how entropy is being assessed to consider it safe for a single SHA-512 hash.
    • If this is to be generator rules, Kerckhoff's Principle applies.
    • If this is user input that's being assessed for strength, it is assuming rules to calculate entropy, that's risky given the motivation for dropping password hashing overhead.

Discussion timeline / summary

• Other users prior to my comments gave a great overview of why that is a bad idea.
• My original contribution into the discussion was to make you aware of the linked blog article assessing entropy poorly.
  • I tried to explain why it was lower but couldn't seem to communicate Kerckhoff's Principle properly?
  • I suggested one way to augment the entropy, describing what 1Password does (they have a whitepaper on it). It is a great way to protect users, but has a slight inconvenience granting access to a new device. For a password manager that is acceptable.
• @voidmain responds about my entropy calculation being off, not considering the "optimal attack" description.
• I respond and clarify that information early into the comment. This time I link to Kerckhoff's Principle.
• @voidman briefly responds, not having the time to review (in all fairness my response was excessively verbose), but fairly certain that I was misunderstanding how to assess entropy.
• I throw in some more information not long after, and roughly 18 months later receive a response to again dismiss what I've said.

Assessing Entropy - Kerckhoff's Principle

Kerckhoff's Principle was mentioned multiple times and ignored.

• You should not dismiss that, as your primary threat is a targeted attack once you're no longer low-hanging fruit (very low entropy) - especially so when targeting you is worthwhile (or you're a vector to a more valuable target).
• That attackers goal is to reduce friction by gaining access to more information about you. There's often bias or policy in place for how passwords are chosen, that can be leveraged.
• Entropy is often lower than it may naively appear to be, the blogpost in question uses an example (correcthorsestaplebattery) with pattern of 4 words (that the XKCD source clearly expresses as 44 bits of entropy), while the blog author thinks the entropy is 117 bit (26^25) via naive attack parameters, not keyspace (input permutations) defined by how the password was generated. A motivated attacker is wiser.

When you dismiss this measure of entropy via the argument "how could they possibly know?", you justify:

1. Only length is relevant, just fill it with the same character (z), they'd be attempting 26^25 or worse right?
2. The attacker would only use the ASCII as input, use a random emoji and call it a day 😎
3. Best of both worlds, take your random letter z, fill the length and replace a random one with an emoji.
4. So long as the attacker doesn't know your very basic rules, your low entropy password is super strong!

It's better to assess entropy by total permutations if you're able to generate a password with sufficient randomness (minimize bias).

I really hope that gets the message across better?

Click for some examples

Examples

Entropy based on Kerckhoff's Principle from passphrases generated at getapassphrase.com.

This is an example of a high entropy password (64 bits):

• "insane deer and comical boar remember rare raven in jordan"
• All lowercase with spaces (easy to input manually), while having some structure at the expense of length (easy to remember).
• Attack time (50% keyspace): 2 years with single SHA-256 (against 10x RTX 4080 GPUs).

Likewise when we have proper KDF involved, (44 bits + hashing overhead):

• "dizzy pig keeps cute paper"
• Reduced length while simple and secure (but you must trust the service is augmenting your entropy via key stretching, like with argon2id).
• Attack time (50% keyspace): 7 years with bcrypt (work-factor 10) (against 10x RTX 4080 GPUs).

Choosing Pragmatic Entropy

Pragmatic amounts of entropy was shared, citing (at a SHA-256 hashrate to iterate through a given keyspace entropy):

• 256-bit: Limits of physics
  • Requires: 2 minutes with earth size attack device, maximum efficiency, and more energy than universe has available..
• 128-bit: Global bitcoin network
  • Requires 72 billion years. Less by now but no where near within a lifetime.
• Energy requirements capable of boiling oceans (114-bit)
• 10x Nvidia RTX 3080 GPUs average success rate:
  • 44-bit: 2 minutes
  • 64-bit: 4 years (or 46 days with 1,000 of these GPUs)
  • bcrypt (work-factor 10): 14 years (44-bit), 15 million years (64-bit)

More insights

From this we can observe:

• 64-bits of entropy is plenty for the majority (but risky the more valuable and thus targeted you are, especially SHA-256).
• SHA-512 extends the time to attack by about 3x (mentioned in linked comment).
• Proper password hashing with the common bcrypt can easily augment that by a million times in difficulty (on the GPUs, which are not optimal for attacking bcrypt). argon2id defends better by being memory-hard in difficulty.

You need a lot more length/entropy to compensate for the cheaper processing of single SHA-256 / SHA-512:

• Becomes impractical the more unique passwords you need as password re-use across services will expose more risk (some less reputable services use plaintext - no hash at all; or your password may be compromised via other means).
• For these same reasons, due to Kerckhoff's Principle, you'd not want to rely on the same password with some variant pattern. The entropy decreases considerably when that pattern can be identified due to those vulnerabilities, a 2nd compromised password may be sufficient to establish the shared material and any pattern for the variants.
• As a result, it mostly becomes useful for a master password and deferring password generation to most services via something that generates enough entropy, the text length can be shorter all that matters is sufficient entropy then.
• If not delegating the growing number of passwords to a manager, either memory fails or the user weakens security by offloading that memory and storing them somewhere that is often accessible to a motivated attacker.

Given the above, lets compare 48 bits of entropy:

• "CL@ni%8#" (70^7.83 = 48 bit, 8 chars + all options via bitwarden)
• "detailed snail summons slim lab coat" (48-bit passphrase via getapassphrase.com)

The passphrase is easy to read, input manually and remember if necessary. If we throw in uppercase or specials we lose some of those benefits, similar to the shorter bitwarden generated password. Especially so for the memory factor as the number of services grows.

For reference, here's how 48-bit entropy compares between SHA-256 and bcrypt, but this time with 10x Nvidia 4080 GPUs (almost double the hash rates):

• SHA-256: 18 minutes (((2^48 / 130e9) / 60) / 2)
• bcrypt (work-factor 10): 111.57 years (((2^48 / 40e3) / (60*60*24*365)) / 2)

That is the lowest entropy, if you shrug-off Kerckhoff's Principle then you can pretend that it'd take much longer. Just consider that the attacker is investing time and money:

• Low value targets don't justify heavy use of resources.
• Higher value targets will optimize the attack to justify that larger investment of resources.

[voidmain]

Thanks for the details response, I’m sure folks that read this thread in the future will get insight from it. I also think we are essentially saying the same thing, just in different ways.

I do want to clarify a couple of points though. A lot of your responses state I’m ignoring Kerckhoff. I want to be clear that I am not ignoring that. I fact, I’m assuming everyone understood that the question “How do we determine if a password should use a weaker or stronger algorithm?” must take into account Kerckhoff. And I want to rephrase from saying “weak or stronger” to “faster or slower”. I think those are more appropriate terms.

Second, your math appears to change. You mentioned 2048^4 as one set size (passphrase based on a dictionary) and then you mention 100 characters of varying lengths for other set sizes. Then it seems like you try to reduce both sets in some cases and then increase them in others. Like if you start introducing capital letters, emoji, or random characters into the passphrase, the set size increases. But if you take 48 Ascii characters the set size decreases based on weak combinations. It’s not completely clear what your point is, but I think we can agree that the size of the set and the length are how you compute complexity and also how you brute force attack the hash (up until a collision which is theoretically infeasible for 512 bits).

And finally, the problem statement hasn’t changed, but perhaps your understanding has. No one has ever stated that XKCD was reality or that we would limit passwords in any way. I mean users can type in whatever they want right?

Let me present some code for how this would work in practice and maybe we can move over into the concrete:

String hash;
if (passwordSucks(password)) {
  hash = hashWithBcyprt(password, 14); // Load factor 14
} else {
  hash = hashWithSHA512(password);
}

This is super simple code and the crux is the method passwordSucks. The algorithm should ensure that passwords cannot be brute forced in reasonable time. Here’s one implementation:

boolean passwordSucks(String password) {
  if (password.length() < 24) {
    return true;
  }

  if (pwnd(password)) {
    return true;
  }

  if (dictionaryAttackable(password)) {
    return true;
  }

  if (repeatsTooMuch(password)) {
    return true;
  }

  // More checks here?

  return false;
}

The other methods called here would exclude what would be “known generators” whereby an attacker could generate the entire sets in reasonable time (like the 2048 dictionary used for passphrase or repeat characters).

Okay, now let’s look at the math.

This function has a base set size of 100^24 (1e48). Each additional character adds an additional permutation set that multiplies the base set by 100. A 28 character password has a set size of 100^28 (1e56).

Each if-check after reduces the set size by some amount. If we assume breached sets contain 1e9 entries, we have reduced the total set size to 1e39 for 24 characters and 1e47 for 28 characters.

If we assume the additional checks reduce the set size by some amount, the final set is the attackable surface. For argument sake, let’s assume we design dictionaryAttackable and repeatsTooMuch to reduce our set by an additional 1e9. Our final sets would then be 1e30 and 1e38 respectively.

In order to brute force 1e30 combinations using SHA512, it would take 1e20 seconds. That’s 3 trillion years for the base length of 24 characters.

Let’s go nuts and bump the set reduction to a whopping 1e15. That’s a huge number, but let’s go with it. That would reduce our set sizes to 1e24 and 1e32. Using the same computational power, it would take 1e14 seconds to brute for the 24 character example. That’s 3 million years for 24 characters.

Okay, let’s drink a bottle of whiskey, punch through the Balmer Curve, and really get aggressive with our reduction. Let’s take it to 1e20. That’s massive and probably a mess of spaghetti code from our drunken coding session, but for argument sake, let’s roll with it. Once we sober up, we would find our set sizes have been reduced to 1e19 and 1e27. Using the same computational power, it would take 1e9 seconds for 24 characters. That’s STILL 31 years for 24 characters.

Basically, we want passwords generated by complex generators (secure random 24+ bytes works) to be hashed using SHA-512 and everything else to be hashed with BCrypt or Argon. This is the original problem statement.

Now, I’m willing to discuss a way that this implementation can be attacked, but I propose we talk about implementation details in code with hard numbers

[polarathene]

TL;DR

Basically, we want passwords generated by complex generators (secure random 24+ bytes works) to be hashed using SHA-512 and everything else to be hashed with BCrypt or Argon. This is the original problem statement.

• Add an opt-in checkbox or config (depending who creates the passwords, user or org). Delegate trust through that instead of heuristics.
• Add the heuristics (acknowledging that it likely has flaws). If it has any user feedback cycle, communicate the risk in trusting the heuristics beyond as a guideline.

---

I think you're making too many compromises for ensuring a reliable baseline of entropy to get away with a single SHA-512 hash. There are better ways to minimize resource usage when that is a priority.

In theory the SHA-512 approach sounds neat, but I just don't see it being pragmatic for real users (EDIT: When it comes to creating their own passwords + heuristics, not externally providing them from generators / managers).

Your proposed approach with heuristics is guesswork on how much lower the entropy actually could be, as opposed to the simpler rules of a generator where you have a far more reliable source of entropy (there's a good reason they're a thing) (EDIT: I seem to have misunderstood, and you're focus is not on heuristics for users creating new passwords via FusionAuth, but detecting eligibility for single SHA-512 hash of externally generated passwords that should have some acceptable entropy baseline_).

• You start at near 160-bit entropy (100^24) and narrow it down to 63-bit (1e19) as your extreme security margin.
• For manual input this is more accurate as user input will primarily be biased. 112-bit for all lowercase (26^24), followed by language and pattern biases you'd lose a good amount of that, while only gaining a little back from the larger charset of 100 ASCII since the actual frequency + unbiased usage of that range would be low. (EDIT: See above edit, I got confused as you reduced entropy for this sort of thing, then finish stating SHA-512 is intended for externally generated passwords)
• To meet your heuristic with enough entropy margin for reassurance, you're realistically going to encounter:
  • Loss in security due to UX and false-positives (heuristic pass when it shouldn't), the password would be better handled via a password manager / generation (EDIT: Which this is apparently only intended for?).
  • Heuristic failure for something actually secure (false-negative), either rejecting the password or falling back to a slow hash defeating the purpose.

You'd still be salting the input into SHA-512 and storing the salt right?

---

How would the heuristics apply to the following?:

• Low entropy, should fail:
  • this is a really good password? Nope!
  • !epoN ?drowssap doog yllaer a si siht
  • ¿Es esta una buena contraseña? Negativo
• High entropy, should pass (based on your acceptable 1e19 / 63-bit entropy example):
  • insane deer and comical boar remember rare raven in jordan (64-bit)
  • 😖👻😴 dizzy pig keeps cute paper (65-bit 128^3 * 2^44, aka 44-bit + 3 random emoji prefix)
  • Q%un!oQ5aKe (67.9-bit 72^11)
  • 7844492364386295433 (63-bit 10^19)

If you're unable to ensure that, false-negative is not too bad for decent passwords, but false-positive on the low entropy is risky. BTW, 36 years becomes 131 days with 100x the hashrate.

For an attack with a single RTX 4080, here's the difficulty:

• Calculation (50% keyspace): (([entropy] / [hashrate]) / [seconds of compute]) / 2 = [time required] (SHA-512: 4.46 GH/s vs bcrypt wf=10: 4 KH/s)
• Q%un!oQ5aK (72^10, 61.7-bit): Approx 13 years (((2^61.7 / 4.46e9) / (60*60*24*365)) / 2)
• <insert example of your password> (100^24 reduced to 1e19 aka 63.1-bit): Approx 36 years
• insane deer and comical boar remember rare raven in jordan: Approx 66 years
• Q%un!oQ5aKe (72^11, 67.9-bit): Almost 1,000 years
• Bonus:
  • detailed snail summons slim lab coat (48-bit):
    • SHA-512: 8.77 hours
    • bcrypt (work-factor=10): Over 1,000 years
    • bcrypt (work-factor=5): Almost 35 years
    • bcrypt (work-factor=1): Over 1 year
  • dizzy pig keeps cute paper (44-bit):
    • SHA-512: Approx 33 minutes
    • bcrypt (work-factor=10): Approx 70 years (((2^44 / 4e3) / (60*60*24*365)) / 2)

---

I'm not sure if I can communicate this any better.

Most of my responses are correcting misunderstandings / misinformation from your end when making statements about what I've said. That is then followed by responses where I essentially rephrase my prior responses, presenting math + sources to back that up in different ways.

If you still believe this is worth pursuing as you've detailed, go for it. I've tried my best to express concerns and feel I have nothing more to contribute to the discussion.

I'll try respond briefly to any follow-up questions, but this should be my last detailed response 😅 (they soak up a fair amount of my time)

---

Original Response

Below I have clarified / corrected statements from your last response, while providing additional math / feedback and food for thought.

Click to view

Corrections / Clarificaiton

Second, your math appears to change.

Just accommodating the context. It remains correct, but if you feel I've made any mistake I'm open to feedback 👍

You mentioned 2048^4 as one set size (passphrase based on a dictionary)

That was when discussing the blog article referencing the XKCD correcthorsestaplebattery comic. That uses 2048^4.

When I provide my own passphrase examples of a given entropy size, they're generated from getapassphrase.com which isn't as straight-forward in structure to calculate like XKCD, but does result in the mentioned entropy.

and then you mention 100 characters of varying lengths for other set sizes.

No that was introduced by you, originally you mentioned a 95 character set with lengths of 25 and 48.

Then it seems like you try to reduce both sets in some cases and then increase them in others. Like if you start introducing capital letters, emoji, or random characters into the passphrase, the set size increases.

I believe you were the one to first introduce random characters into a passphrase, and suggest other modifications to raise entropy, while capital letters was already part of your original 95 ASCII charset? 🤷‍♂️ I just went along with it.

The emoji were introduced to highlight some concerns I raised with what you were saying, but that didn't seem helpful to you, ignore it.

I'm only concerned about entropy. Using words that are all lowercase as input (instead of individual letters) works great.

But if you take 48 Ascii characters the set size decreases based on weak combinations.

Not really an issue?

If you chose 48 random ASCII characters, and have a length of 23 with no bias in the sequence, you get over 128 bits of entropy (log2(48^23)).

It’s not completely clear what your point is
I think we can agree that the size of the set and the length are how you compute complexity and also how you brute force attack the hash (up until a collision which is theoretically infeasible for 512 bits).

You simply don't brute-force attack once it becomes pointless.

• A naive attack would allocate some small resource on you and move on.
• A targeted attack may invest some resources blindly (but if they're not able to predict the cost required, it'll not go too far either).
• SHA-512 should roughly hit a collision before reaching 256-bit size IIRC. Not that anybody would bother to hunt a collision for that hash since it's not practical.
• 128-bit is ridiculous for entropy already, you can have the entire crypto mining network and not be successful (approx 331 EH/s: (((2^128) / (331e18)) / (60*60*24*365)) / 2) = ~16 billion years average success rate). We're talking all oceans in the world could be boiled away with that kind of energy requirement..
• If the attacker wants access, they're going to have to find an alternative option.

---

Collapsed as largely redundant now + my mistake for potentially misinterpreting primary intent for heuristics

I mean users can type in whatever they want right?

I don't know? That is decided by how FusionAuth want to approach such a feature? (I don't use the software, doesn't matter to me)

If you want to offer the user a way to have a secure password, give them a reliable password generator like getapassphrase.com or BitWarden offer. Something that ensures a solid baseline of entropy. The user will probably have some bias in selection, but the easier they are to remember or manage, the less of an issue that is.

I think trying to support any input and assessing that by your own rules is more flawed, you'd probably be misleading some users and I doubt they'd care much between the two choices. Nothing is stopping you from offering both DIY and secure generator 🤷‍♂️

EDIT: While reading your response, I see you suggested heuristics that fallback on failed check to slow hashing.

---

The algorithm should ensure that passwords cannot be brute forced in reasonable time.

Just offer generators that ensure that.

It's not your job to attempt to assess entropy from untrusted inputs from users. You'll find plenty of resources where that has been attempted and has not proven to be reliable.

The other methods called here would exclude what would be “known generators” whereby an attacker could generate the entire sets in reasonable time (like the 2048 dictionary used for passphrase or repeat characters).

If you want to support some heuristics for DIY inputs, go for it.

Probably better to just use existing solutions already out there that have gone through this sort of thing for you already and done a best effort, but I wouldn't place trust in it personally for ensuring minimal level of entropy, only as a guideline to nudge users towards more secure passwords (often though, it encourages the wrong approach anyway which ironically lowers security through other means).

A dictionary check is only as good as the dictionaries you have... Are you going to select words by some sort of ranking like frequency in literature, password leaks, accommodate for modifiers (especially common ones), other languages? What about legitimately secure passphrases, will you set off a false-positive accidentally?

• dizzy pig keeps cute paper is an example of a 44-bit strong secret, pair that with a slow hash (bcrypt work-factor 10) and it'd take 7 years on average with 10 Nvidia RTX 4080 GPUs. That's assuming the attacker already knows the exact rule-set to match that 44 bits of entropy (it's not just 5 words randomly sequenced from a single dictionary - it's multiple dictionaries to conform to a specific sentence structure). If the attacker does not know that, the difficulty is higher.
• insane deer and comical boar remember rare raven in jordan: 7 million years.. (64 bits of entropy)

Just do something like that, or endorse password managers that generate unspeakable gibberish. Pair that with 2FA / MFA, job done 😎

Basically, we want passwords generated by complex generators (secure random 24+ bytes works) to be hashed using SHA-512 and everything else to be hashed with BCrypt or Argon. This is the original problem statement.

Right.. so knowing how biased humans are for DIY input, (despite accounting for all that entropy reduction in the process makes sense)... you'd still not know some heuristics like "is this totally secure looking password used anywhere else, just waiting for the user to get compromised on any of those platforms?"

qwerty12345UIOP67890asdf! (24 chars)

• Some pattern bias to workaround whatever requirements are enforced, typical placement and choice for a special char
• Can you add rules to detect that... sure? But do you want to be maintaining such a thing...at what point does the user get frustrated (or the feature lose it's relevance because the majority are just given the slow path fallback anyway)

Might as well just generate the randomized password?:

• Q%un!oQ5aKe@as&zzk29!KdX (24 chars, 148-bit)
• Alphanumeric, lower+upper case, 10 symbols, total 72 chars (bitwarden generator charset)
• Your worse-case 1e19 size is approx 63-bit, which we can match approximate with this pattern at 10 char length (61.7-bit), or with 11 chars (67.9-bit). Reduced entropy representation: Q%un!oQ5aK (10 chars, 61.7 bits)
• Using some light slow hashing can augment a 44-bit passphrase to a similar difficulty while being much easier to remember and input.

---

That’s STILL 31 years for 24 characters.

Sorry, in your response you didn't mention how you're calculating that time. In my previous one, I cited previous mentions of 10x Nvidia RTX 3080 attacking SHA-256, and updated it with the newer 4080 generation.

1. Nvidia RTX 4080 hashrate for SHA-512 is 4460.2 MH/s (4.46e9, or for 10x units: 44.6 billion / sec)
2. log2(1e19) = 63.12-bit (100^24 reduced to 1e19, aka 63-bit entropy)
3. ((2^63.12 / 44.6e9) / (60*60*24*365)) / 2 = 3.56 years

Looks like you were roughly basing that off 1 RTX 4080, is that correct? (35.63 years to reach 50% of keyspace)

I'm not sure what an example of your 24 char secure password would look like, but it's probably somewhere between these two (single RTX 4080 at 50% keyspace):

• Q%un!oQ5aK (61.7-bit): 13.32 years, add one more char to length for at least 67.9 bits and you have approx 979 years.
• dizzy pig keeps cute paper (44-bit): 32.87 minutes (SHA-512) vs 69.73 years (bcrypt work-factor 10: ((2^44 / 4e3) / (60*60*24*365)) / 2).
• detailed snail summons slim lab coat (48-bit): 8.77 hours (SHA-512) vs 1115 years (bcrypt wf=10, even at wf=1 it's still over 1 year, and wf=5 is almost 35 years)

Just look at the difference bcrypt is making there for 44-bit. If you're comfortable with a security level of 31 years, drop the work-factor by 1 and halves to approx 35 years. If you like, keep lowering the work-factor.

Keep in mind that the security concern is with the targeted attack who has far better resources (RTX 4080 are not the best hardware for bcrypt hashes to dollar ratio; so consider a decent amount of margin when the value to attack is high).

The great thing about the examples I've provided is that Kerckhoff's Principle is in full effect. No reduction needs to be accounted for - that is the best attack to optimize for, no false-positives to worry about. However passphrases like that are not as useful for a single SHA-512 hash, as the required length becomes less reasonable, but probably still better UX for manual input / recall.

---

Before writing any code, consider:

• How these heuristics would be approached, look into existing solutions and their experiences, how well did they actually work.
• How many users passwords would pass those heuristics or go to the fallback route if there is no feedback cycle with the user.
• Realistically what is the load-level impact on a system like; what sort of resource / cost savings are you gaining with SHA-512 vs relaxing the slow hash settings to be less intensive when a baseline for entropy is guaranteed.
• Are you harming UX (and thus security) with these heuristics for the users input to pass.