What Industry changes do we need?

I know everyone says this, “We need to re-think our approach to cyber security”

So let’s rethink it.


The short of it is, there is no one defined right option. All that leads to is trends, any trend, including random password generators, can be refined if everyone uses them.

A random password generator would create a subsequent trend of password managers, which would inevitably re-shift focus for attackers if everyone started using them.

When I think about what would make it challenging for me and what would make it easy for me, I always return to the same thing

Consumer Trends make attacks easier

If there were no trends, attacks would be significantly harder.

In this case, trends are what allows an attacker to step away from traditional brute force into a streamlined attack.

Now human beings will always fall into trends, we really are not as unique as we would like to think, or at least never in a good way, so it would stand to reason that we need to create more trends and provide more options to remove trends from password attacks.

It is not that there isn’t different advice out there, it is just that in this particular topic a lot of that advice seems to approach it with a hard headed “This method is right, everyone else is wrong”

Don’t do this

Never do this

Always do this

The other problem I commonly find is the attacks are not explained in a reasonable way, the entropy calculations for a method are lazy, usually on assumption, so I can recalculate entropy based on a random password generator being used by everyone to re-prioritise my attack, as a randomly generated password would now formulate into a probable/not probable password hierarchy based on character combinations.

Not really any different from calculating the odds of winning the lottery, it is just more complicated.

As an industry, we then always fall back to “The method is secure, it is not my fault, it is users”

But there is this mad expectation that every consumer should interpret my instructions in the correct way.

Look at it this way

Let’s say every user has a password, it is just a word, no numbers, capital at the start, no special characters.

Then this statement is made

“Adding a special character to your password makes it more secure”

Well it doesn’t really does it, because that can easily be interpreted as

Original Password = donkey

New Password = donkey!

If I were to calculate entropy in a lazy way, I would go from something like 19 Billion to 32 Trillion combinations.

Reality is, assuming there are 350,000 words in the English language including names, places etc. would be going from 350,000 to 11 million combinations.

So even at 1000 attacks per second, we go from 5 minutes to 3 hours by adding the special character, in an offline attack, both are likely covered in the first second or so.

So, what would would the entropy calculation be for this?

Original Password = antidisestablishmentarianism

New Password = antidisestablishmentarianism!

Well, it still goes from 350,000 combinations to 11 million combinations based on that structure.

This is what we demonstrated on the spreadsheet on our first page of this article (link below for reference)

In short, structure has to be considered when calculating consumer Entropy

Then when we look at a concept, we have to look at it in conjunction with everything it overlaps with.

So, I can’t decide for a person whether they should use a password manager with a randomly generated password unless I know the device, the network the device is used on and the method of password manager itself.

So when considering, for example, a password method, I would need to take Device, Network, Application, Application Location into consideration (among other things).

To give another example, let’s think about Phishing

Can I make this statement?

“Hover over URLs to see where they are going?”

No, I can’t make that statement to consumers and it be true, because if I consider Device, Network, Application, Application Location, what I conclude is that this advice does not work for everyone, it does not even work for the majority all of the time, it is a specific consideration which changes dependent on where the individual is and what device they are using and where the link is present.

What you probably find is, this advice works for individuals 09:00 – 17:00 Monday to Friday, excluding break times, then all other times it is a ‘Kipper Rouge’, or in other words a red herring that exposes you to phishing.

So what do we need to do?

Well, we need people to come up with more methods, and structure their methods around overlapping points, not what is easiest to define.

So if I were to sum up the problems I just laid out above with the industry into a couple of points, I would land at something like these points

1. Rules do not inspire creativity, but options do.

2. A single option or method cannot be right, but it can be wrong

3. Lazy Entropy calculations creates bad security

4. Lazy Attack Explanations creates bad security

5. Security issues are a collection of considerations, not considerations in isolation

Now as I review different methods, I focus on these 5 points

Password Manager example

Now if we take a password manager on a secure business network, we pretty much end up with “Yep, that is what we want”

If we take that same concept on a consumer device and non-secure network, we land with, “well, that could actually be worse”

Then when we consider unknown changes in technology for consumers, we find that how they were conditioned to work 10 years ago no longer applies.

Devices have a built in password manager, go back far enough and these were secure enough for consumers, this is where your browser says “Do you want me to remember the password”

Traditionally this would be stored on the local device, so arguably I would have to expose your physical device in some way to get these passwords.

Today what you will find is that the same prompt may very well be storing that password in plain text on an off-net application, Gmail for example, so if Chrome prompts to store a password and you are signed into you Google account at the time, you can see this in plain text on your google account.

Password Rules Examples

If we take an application where the rules are enforced, we find that on point 3 above if we calculate entropy correctly, that we maybe don’t want these enforced rules.

  • Must contain 1 Upper Case
  • Must contain 1 Lower Case
  • Must contain 1 Special Character
  • Must contain 1 Number

If these rules are known to the attacker, which is an assumption we should make for calculating entropy, we can remove roughly 70% of combinations from an entropy calculation.

I can demonstrate 33% with one rule, to demonstrate the 70% requires adding back in and deducting different combinations (for the purpose of this article, just take my word but we do varying entropy calculations in later articles), but lets take a 10 character password

Total Combinations = 95^10

Roughly 60 Quintillion combinations

But because the rules are enforced, it tells me that there are combinations not to try, the biggest hitter being the Numbers

So how many combinations do not contain a number?

Combinations without a number = 85^10

Roughly 20 Quintillion combinations

So if we said we were cracking this password, it would likely require an offline attack. But lets show varying attacks per second from 1000 to 100 billion and just see what we land at without considering the type of attack

The time below is in years

Number of attempts per second Time to run based on all combinations Time to run if we remove combinations that do not contain a number Time to run if we remove all invalid combinations
1000 1902587519 1255707763 570776255
10000 190258751 125570776 57077625
100000 19025875 12557077 5707762
1000000 1902587 1255707 570776
10000000 190258 125570 57077
100000000 19025 12557 5707
1000000000 1902 1255 570
10000000000 190 125 57
100000000000 19 12.5 5.7

We then assume that the average time to crack a single password is 1/2 of this on a pure brute force. So this displays the maximum amount of time to run all valid combinations.

Point is, in this example, by considering my main 5 points, I can see that by imposing rules I remove the element of randomness, in short, my 10 character password where rules are strictly enforced like this results in the password only being 30% of the strength I thought it was.

Now I can increase entropy without decreasing combinations with a simple change to my rules if I really must enforce them

  1. Must contain 1 Upper Case
  2. Must contain 1 Lower Case
  3. Must contain 1 Special Character OR 1 Number

Simple change to the rule means that what I can remove from my brute force attack across the board is minimal, I’d be lucky to strip away 10% of invalid combinations from this based on the rules alone (there are some other reasonable methods to deploy).

So it changes the scenario from a certainty into a risk based approach, so I could still treat all passwords as though they must have a number, but there is no guarantee my crack would work.

Essentially, there are not enough numbers to create a decent pool for an enforced rule on their own.

My examples in this article

Well currently my solution for writing a password on the previous page does consider these points, but not fully

1. Rules do not inspire creativity, but options do.

2. A single option or method cannot be right, but it can be wrong

3. Lazy Entropy calculations creates bad security

4. Lazy Attack Explanations creates bad security

5. Security issues are a collection of considerations, not considerations in isolation

I explained the attack, and provided a tool where the non-technical user in theory could replicate the process of building a data dictionary. I don’t think I was lazy there, I think I proved my point reasonably well.

I think I can simplify the tool (which I do for the password writing methods) by stripping away most of the explanation, leaving tables with run times and a sheet that shows passwords being generated.

I listed a collection of considerations, writing a password was not where I started, I started with where we enter passwords i.e. non-secure networks, as that undoes our password complexity.

I considered Device, Network, Application and Application location when defining my solution, so point 5 has been considered.

My Entropy Calculation was lazy though, I have not followed my points 1 and 2. However, this is not my article for “Methods for writing a password”, which will be present after this, that is where I provide multiple methods for defining passwords, along with drawbacks, benefits, other considerations etc.

But point 1 impacts point 3 quite a bit, in order to highlight the issue with point 1, I needed to calculate Entropy around the rules.

Now I know my realistic entropy is not 95^15 for my password example.

It is closer to 72^15

7.5 Octillion as opposed to the previously stated 463 Octillion combinations

The reason being is that I prescribed a method, but I didn’t encourage creativity, specifically around the special characters.

So what we will likely find is that consumers are drawn to the same 10 special characters they are used to using.

So this method is actually 1.6% of the total strength I thought it would be, strength being the total viable combinations.

It is still a very reasonable password for 2018, it is unlikely to be cracked by brute force, but, the same thing was true of this password a few years ago


Now the current advice is 8 characters or more

I think most of us think this is bad, but the entropy for 8 characters is 95^8 or 6.34 Quadrillion, we know that in an offline attack an 8 character random password can be cracked pretty quickly.

But because our special character pool is actually likely drawn from a common set, we could argue that it is 72^8 or 722 Trillion. Just dropping Pipe on its own takes away 5% of combinations to try.

Now if you go back several years, an 8 character password took several millennia to crack with brute force.

Point is, time is not on our side for password strength, so, if what I suggest to people creates a password that is 1.6% the strength I thought it was, how does that impact the real time it would take to crack a password?

Well, if we couple that with consumer advice from Gov UK, which is that you shouldn’t tell consumers to change their passwords, then all we know for certain is I will get caught out at some point.

It will get to the point eventually where someone will say that my password structure and length would take “200 years to crack”, the reality being that it takes 2 years due to my lazy entropy calculations.

That’s the important bit for Entropy, it is not how long the password takes to crack on today’s technology, it is “with rising technology, at what point does my password fail”.

So if I were to recalculate Entropy year on year for this method, at some point I will misinform consumers on the basis that it still takes a long time to crack, when it simply doesn’t.

My method doesn’t cater for enabling consumers to pick from the full set of characters available, we know passwords fall into trends, it is a reasonable assumption to define 10 special characters that we are going to see in passwords.

So while the method deployed could be the best one ever invented, my lazy approach to Entropy means that at some point in the future I will have guided consumers to a point where they still believe their password would take a long time to crack, but inevitably it would be a short time to crack. Roughly 1% of the total time they think.

At that point, we see my method fail.

That could be years down the line, but equally I could argue that with Fibre Technology program due to complete 2035, introduction of powerful gaming into the home (VR, complex gaming AI) and the push for “Big Data” analyses, all of which would imply an improvement in networking and processing, we would consider these all to be a “Positive” influence from a cyber crime perspective, i.e. I as a criminal should see my run times significantly reduce over the coming years with contributions from multiple aspects and an increased rate in technology being driven by consumers and businesses requirements, reducing my required investment in technology to achieve my end goals.

We summarise on the next page

Previous PageNext Page

Back to How I Would Commit Cyber Crime