1

As I understand it, by using one-way encryption we can protect stored password data in the event that they are stolen. Broadly speaking, password data can usually be cracked by guessing so the strength of the password protection could be measured as the computer time we would expect a brute force attack to take.

However, computation time isn't a good metric by itself because attacks can be parallelized and, more importantly, some encryption methods can be more easily parallelized than others. "10 years" has a very different meaning depending on whether an attack is embarrassingly easy to parallelize or if it is very resistant to a parallel attack.

Assuming we know everything we can know (algorithm, quality of salt, password policy, iteration count, number of passwords, etc...) and we fix our assumptions about the techniques available to an attacker, then, is there a reasonable indicator of how well protected password data is in the hands of an attacker (even if it were only 'accurate' to a couple of orders of magnitude)?

E.g. is financial cost a reasonable metric? Could an indication of "$1,000 per password cracked" very loosely estimate the protection of a password? E.g. an attacker with massive resources might crack one every second while another might crack one every month but (within a couple of orders of magnitude) it costs each $1,000 per password.

If cost is no good at all, is there any metric that can be used to communicate to the layperson the relative strength of password protecting designs?

  • Time and resources available are somewhat related. With more resources, you can decrease time and vice versa. I think time becomes a better metric when you have an attacker with a certain capacity in mind (x years for a script kiddie to crack, y months for a government agency, etc.). – grc May 28 '16 at 16:17
  • I agree, but doesn't that move the question to how to measure the capacity of an attacker? If I need the password to be safe for 6 months then the question becomes "how much capacity does the attacker need to crack it under 6 months?" and then the communication is "It's safe from an attacker with less than 3.67 Giga-Something" which, by itself, will mean little to the layperson. – codybartfast May 28 '16 at 16:53
  • Computation time is actually a very good metric, as we know how to categorise and estimate the compute power for various threat actors. – Rory Alsop May 31 '16 at 12:20
3

Financial cost is also not a good metric. Moore's law can be used to derive that chip performance would double every 18 months. This results in greater computational power at the same price, hence it might cost $1000 per password today, but it will be $250 per password in 3 years time.

In my opinion, time is still the best metric because it can be tied to your organization's password policy. If your observations are that the current password strength would require 10 years to brute force, and you are 80% confident of the accuracy of your estimate, then perhaps you might want to force your users to change their passwords at least once every 8 years. Even if your observation turns out to be incorrect due to hardware advancements and the password is cracked within the margin of error, your users are still safe since the passwords have long been changed.

  • Sorry, I should have said 'computation time' (just edited). Wouldn't the elapsed time depend on the resources of the attacker? And then 10 years of computation time could be achieved more cheaply and in less elapsed time with a SHA, than with bcrypt/pbkdf2? I.e. a bcrypt based design will take more elapsed time than an SHA solution even if both have a theoretical computation time of 10 years (because of key stretching and RAM requirements). – codybartfast May 28 '16 at 16:26
2

The following is a technique I created to express password protection strength to clients. It is a very crude one but gives a very clear picture to a civilian.

I can't guarantee its quality or fitness for use in your situation, but here goes.

The BadMan Scale

Component

It consist of three parts

  1. Type Of Attacker - Classified as following [A]

    1. Individual person (spending up to $10K / Resource high end computer)
    2. Organization (spending from $10K to $1M / Cluster)
    3. Government (spending above $1M / Large computing cluster)
  2. Time to success in months [B] (At current computing speeds, on

  3. Bit length of final hash value [C] (128, 256 etc)

Structure

The values are expressed in form of [A].[B].[C] for example if a password has expressed in Sha256 can be cracked in 2 years by an organization size attacker the value would be 2.24.256

Larger value is better.

  • Thanks BMC. I like the BadMan name! I think it captures the three main components: [C], what we do; [A], what the attacker can do; [B], how long we can expect a password to survive. It seems clear from @limbenjamin, grc and your response that ultimately "time" is a vital indicator because our primary objective is something like: "Keep passwords sufficiently safe within their useful life time" – codybartfast May 29 '16 at 8:32
0

Near term ratio of discovery cost to value.

For example one could say something like:

Today, given this design, and a password created in the next 12 months with a usable lifetime of 90 days, then the estimated cost of cracking the password within its usable lifetime is $15,000. Given an estimated value of $750 for a password this would give a 20:1 ratio of cracking cost to value.

This may be simplistic, but I think to estimate how 'safe' a password is we have to include an estimate of the password's value. This could be the financial value to the attacker: e.g., passwords for a bank account or bank employee have a different value to those for a review site. But it could could also be an estimated value of reputation damage for the company, or a minimum cost of being responsible (because users will reuse passwords we shouldn't allow a password to be cracked easily even if it has low value by itself).

The cost of cracking a password would I think comprise two main factors:

  • The computational difficulty, which reflects the design and policy (password length, password complexity, encryption algorithm, salts, iteration count, ...)
  • The estimated cost of computation, which would depend in part on the ease of parallelization and potential economies of scale for an attacker.

Personally, I've no idea if 20:1 is a good ratio, or given the number of compounding estimates, if it is quite a poor ratio.

It may be quite a simple model, but it could enable discussions on password safety without having to introduce concepts like keyspace size, entropy or CUDA core counts.

  • I like your idea. How would you compute the financial value of a password for a generic forum, or even for a social network? I think that companies have ways to measure these values (e.g. reputation damage), but for individuals it could be more difficult. – A. Darwin May 31 '16 at 11:41
  • Thanks @A.Darwin. I think there should probably be a minimum 'good hygiene' cost we impose on an attacker for any passwords (if only because of password reuse). That would cover most general forums. I wouldn't like to say if that minimum should be $1, $10 or $1,000. I think every part of the estimate is hard, and beyond my skills, I guess I'm putting the suggestion out there to see if folk think it's a reasonable measure and if it will make sense to 'civilians'. – codybartfast May 31 '16 at 12:11

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.