Is there a civilian friendly indicator of stored password safety?

Question

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?

Answer 1

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.

Answer 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.

Answer 3

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.