# Are randomly-generated passwords starting with "a" less secure?

I generated a password recently for a new account and the first three characters were "aa1".

After exhausting all other attacks, a cracker would start brute forcing. On the assumption they'd start from "a", my password of "aa1" would be cracked faster than, say, "ba1", and that faster than, say, "za1".

This password was very long so this question is more theoretical than practical. (Unless password lengths are limited, of course...) Are my assumptions right about brute-forcing and passwords?

• brute-force would probably be parallelized, so if you have 26 running attack instances, then the 1st starting lowercase letter does not change a thing, but the question is pretty interesting : ) Jul 10 '19 at 14:17
• If so, just use "zzzzzzzzzzzzzzzzzzzzzzzzzz" as the safest password there is.
– IMil
Jul 11 '19 at 5:09
• You assumption that an attack will start with 'a' may be incorrect. Jul 11 '19 at 12:36
• If everybody knows passwords starting with "a" are less secure, in a rational world people will never use them. Therefore, passwords starting with "b" are now less secure, for the same reason. Rinse and repeat. Conclusion: it is impossible for a secure password to have a first character at all :) Jul 11 '19 at 12:53
• Clearly "acorrecthorsebatterystaple" is safer than "correcthorsebatterystaple" but not as safe as "manycorrecthorsebatterystaples" Jul 11 '19 at 15:24

It would seem that it depends on how exactly the attacker is going to bruteforce your password. However, my opinion is that in the end it doesn't matter.

A serious attacker will never start from the beginning in alphanumeric order, from aaaaaaaa to 99999999, unless they know they can do that in a reasonable time. If that's going to take them a thousand years, why should they use that method, knowing they will necessarily have to stop at, say, cccccccc? But if the attacker knows that they can try all the possibilities in a reasonable time, then it doesn't matter whether your password is among the first combinations or among the last, because in the end they will find it anyway (in a reasonable time).

• Indeed, I think that's what it really comes down to - the hacker is well aware of what their has rate is, and therefore what passwords they can crack in a reasonable amount of time. Bruteforcing the full search space is either possible in a reasonable amount of time or it isn't, in which case they won't bother and it won't matter. Jul 10 '19 at 16:27
• .... unless the random password generator came up with 'aardvark' Jul 11 '19 at 0:34
• @SamuelÅslund, if "banana123" is considered insecure, "banana123zzzzzzzzzzzzzz" is definitely more secure, but it's hard to say exactly how much that is going to help. Some attackers might try to append or prepend stuff to basic patterns (in the end, appending or prepending stuff is still going to be a pattern), but there's no way to know. The best practice, and the only one that's guaranteed to be secure, it to use passwords that have real entropy and don't rely on tricks, mnemonics, and password reuse.
– reed
Jul 11 '19 at 17:31
• Perhaps this is a reason to have hamsters instead of dogs. A dog lives 10-13 years (roughly) while a hamster lives 2-2.5 years. Using hamster names instead of dog names increases the search space by a factor of 5? Jul 11 '19 at 19:13
• @Tezra that's one way to measure entropy in human language, but entropy itself is a complicated topic with varying definitions in different fields (physics, computers, information theory, etc...) Jul 11 '19 at 19:44

## Entropy

Entropy is really the biggest concern, and entropy is determined by the amount of randomness in your password generation process.

Let's use an 18 character password as an example. We'll look at alphanumeric characters only (62 possible characters). This gives:

log2(62**18) = 107 bits of entropy

If you decide to always convert the first 3 characters to Z to make it harder to bruteforce then you have effectively removed 3 random characters from your password, leaving you with:

log2(62**15) = 89 bits of entropy

Which is about a factor of 1,000,000 weaker. Of course, both are still absolutely and completely impossible to bruteforce, so if someone is trying to brute force your password I wouldn't worry.

## Cracking strong passwords is impossible

However, it's worth emphasizing how impossible it is to brute force such a password (just in case my links didn't convince you). A top of the line MD5 hashing rig can try 200 billion hashes per second. It's blazing fast (which is why MD5 isn't supposed to be used for passwords). Even your weaker password (when you replaced the first three characters with z) has 7.6e26 possible combinations. At 200 billion hashes per second it will only take 120 MILLION years to try all password possibilities if the password was hashed with MD5. I don't think you have anything to worry about.

## The impact of aa

So, is it better to start with "higher" characters to make it harder for someone to brute force your password? Maybe, maybe not. If an attacker happens to start at the beginning of the alphabet then sure, yours will get cracked "faster" (although still not in this lifetime). However, there are no guarantees that someone attempting a brute force would operate in that particular order. As a result, it's impossible to guess whether or not a password starting with aa may be more crackable. Again though, if you use a long random password, there is effectively zero chance that it will get hacked. So I wouldn't worry about it. When it comes to passwords length is king.

I think that Kerchkhoff's principle is very applicable here. This is, in a sense, a core "tenet" of security. The idea behind Kerchkhoff's principle is that the security of a system should be based on one, and only one, secret/key. The idea is that the more "parts" are needed to keep a system secure, the more likely it is that some parts will get leaked and a security breach will happen. When we're talking about passwords it's quite clear what the "key" is: the password. Specifically, a long and random one. As discussed above, it's really all you need. By adding further "rules" on top of your random password you're really just giving potential hints to make it easier for an attacker who is targeting you to guess your password.

• This sort of "clever" reduction of entropy by removing "easy to guess" patterns goes all the way back to the Engima machine. For example: no rotor could be in the same spot two days in a row; no two plugboard connections could be adjacent; no rotor settings could repeat in a month. Once the codebreakers worked out what the procedure was these all reduced the combinations they had to search. Jul 12 '19 at 3:43
• @Schwern that's possibly the best comment ever. I think it would deserve to be an answer itself. Jul 12 '19 at 9:39
• Comments are not for extended discussion; this conversation has been moved to chat. Jul 15 '19 at 7:38

After exhausting all other attacks, a cracker would start brute forcing.

Says who?

There are only two scenarios in which brute-forcing is actually a thing. One is when the attacker has the password hash and the other is when he has control of the software controlling the login because any non-totally-broken software wouldn't allow him to brute-force in the first place.

The most common case is that the attacker does have a password database. He will be using a cracker software like John the Ripper. He will have tested a few million possible passwords before he even starts with "aa". In most cases, at this point he already has cracked several thousand accounts because their password was "password" or "12345678". Or - to satisfy the dummy "password strength" checker - "Pass123!".

He probably won't bother letting his cracker run into the actual brute-force step, because he has better things to do with his time. And you actually don't know if brute-forcing would actually start at aa or not, because there's a good chance it wouldn't.

Your real problem is that as soon as you make rules about which passwords you consider "bad", you actually reduce the search space. Password policies are harmful, as it turns out. Look, the author of JtR even has a page about that on his wiki. Of course the \$\$\$ consultant who convinced your CISO to adopt his stupid password policy never read that page and probably doesn't even know JtR still exists. :-)

So no, "aa1" is not appreciably less secure than "zz9". Firstly because brute-forcing is the last weapon, not the first and secondly because there is no guarantee that the brute-force software actually starts at a and not at z. I would not start at a if I were to write one. I'd randomize the alphabet and use that, for example. Exactly because I'd figure people probably avoid "aaaaaaaa" as a password.

• Sadly, according to haveibeenpwned.com/Passwords the password aaaaaaaa has indeed been used, leaked and broken over seventy thousand times. (zzzzzzzz comes in at 54k and llllllll at 7k.) Jul 11 '19 at 18:31
• That's almost nothing, compared to, say, "password" with over 3.6 million times or "secret" (which is just 6 characters) with almost a quarter million. :-)
– Tom
Jul 11 '19 at 19:40
• That's true. It's definitely not the worst password in the world. :) Jul 11 '19 at 19:48
• Actually, a lot of attackers use brute force as their first technique, although they'll only brute force, say, 4 characters before moving on to better attacks like dictionary and hybrid attacks. Jul 12 '19 at 7:20
• The JtR wiki page you link to about password policies doesn't really back up your argument. It says that for an ASCII password of length 8, requiring at least 3 character classes only reduces the search space by 5.5%, "so it is a reasonable thing to do". Some authorities may assert that "password policies are harmful" but that particular page does not. Jul 12 '19 at 11:12

A lot of the other answers are focusing on why a password starting with 'a' would not be less secure than any other starting letter because you're assuming that the attacker is doing it sequentially vs parallel, or because you're assuming they are starting from 'a,' when a skilled attacker might not. Because of these arguments, no starting letter is any less secure than another from a skilled attack.

However, I would argue that against a naive attacker, a password starting with 'a' is marginally less secure, due to the fact that they would be more likely to do it sequentially and starting from 'a' as a result of their lack of skill and experience.

In practice, though, like the other answers said, this won't make a difference because in practice, a long enough randomly generated password will likely never be able to be brute forced in a reasonable amount of time, and avoiding the letter 'a' would just narrow down the search space.

# Thinking out of the box: Correcting for threat model

A lot of the existing answers already indicate that there is little to gain by simply avoiding the a, and that it is very easy to apply a 'fix' that actually makes your situation worse.

HOWEVER, conceptually it also feels wrong to ignore the attackers way of working completely. Therefore I present this solution direction, that should work in theory (but may be a bit hard to apply in practice):

If your threat model defines an attacker is more likely to attack a pattern, it would be good to make the occurrance of this pattern less likely

Example:

1. Suppose you know there are common tools that brute force passwords from 'a' forward
2. Suppose these are typically configured by allocated time/tries, which happens to come out to them trying the 'a' more often than the 'z'
3. Suppose this results in the total number of made attacks against you by everyone in the world, this results in the 'a' being tried 2% more often than the other letters

In this case it would probably be good to make the 'a' 1% less likely

# Conclusion

If you have (and keep track of) the real threat against you, you should be able to slightly reduce the chance of your password being cracked. Unfortunately you would need a giant company to know the status at any time, and you would need to re-generate passwords every time the threat model changes. For instance because the attackers also learn that you are correcting for the patterns of last week.

In short, realize that you were conceptually right, but it is just impractical to implement properly.

When you assume a brute-force attack, a password starting in "a" might be weaker. If using "z" gets popular, this would be true for "a" and "z", what would make it more complicated to assess the risk.

Lets assume we know a character that is tried before others. Then the attacker only needs to test 1/26 of the search space. The solution is, to make your password longer. Not only when it starts with "a", but always.

A attacker will probably start with short passwords for a brute-force search*, so your longer one has much better protection. Even when he does not, he will need to test many more passwords before getting yours.

A dictionary attack or mixed attack may try "a", "aa", "aaaaaaaa" before trying "b", though. This is a mind game between the attacker and you, so choosing a random passphrase is the best approach and rejecting ones that may be in word lists is reasonable (but a random long password is unlikely to be in a wordlist, anyway).

* Testing all 1-8 char passwords needs only about twice the time as testing all 9 char passwords starting with "a", so it is reasonable to start with shorter ones, if there is a possibility that the password is short.

• Why do you assume that a bruteforce attack will start at "a"? Jul 11 '19 at 13:13
• @T.Sar I don't think it's an unreasonable assumption. You have to start somewhere and this is the first letter in the alphabet and in the ASCII/unicode table. It seems as likely a place as any (an attacker wouldn't want to have to keep state of each password they already checked, so there must be a sequence, i.e. it won't be random, and from experience, A is what did myself in my scriptkiddie days).
– Luc
Jul 11 '19 at 13:21
• @T.Sar I followed the assumption in the question and based my answer on this assumption.
– allo
Jul 11 '19 at 14:02
• The number of 9-char passwords (N^9) seems to me about (N-1) times larger than the number of 1-8-char passwords (N^9-N)/(N-1), where N is the alphabet size. That is considerably larger (unless we are in the well-known case N=2). Am I missing something?
– wimi
Jul 11 '19 at 14:51
• Indeed, I mixed this up. I hope its correct now.
– allo
Jul 12 '19 at 10:06

Strictly speaking, yes, if the cracking comes down to brute force, there might be a higher chance that a password starting with "a" will be checked before a password starting with "z". It's not necessarily true, but it may well be.

An important thing to understand about password entropy is that you have to calculate it wrt. the model the attacker will likely use to crack passwords, not wrt. the model you have used to generate it. For example, if you generated a completely random alphanumeric password and you got "passwordpassword123", it has the same "generation" entropy as any other random password of the same length. High "generation" entropy doesn't make it a good password though, as it has very low "cracking" entropy assuming typical dictionary attacks.

It's not unheard of discarding randomly generated passwords exactly for this reason. While discarding reduced the number of available passwords (and thus reduces password security), it avoids generating a password which would be very easy to crack.

• "It's not unheard of discarding randomly generated passwords" Do you have an example? Aside from 4 digit PIN codes, I don't think I ever heard of anyone discarding weak random passwords. If your random password generator generates "passwordpassword123" before the heat death of the universe, it can't have been a good generator in the first place.
– Luc
Jul 11 '19 at 11:42
• @Luc Or maybe you're just really lucky and need to go play the lottery... Jul 11 '19 at 12:16
• @ConorMancone Not really. If you assume that all 8 billion people on this planet each create a new account every second (so they each generate a random 16-character password every second), it would still take 94 billion years before there is a 50% chance that someone generated "passwordpassword". If you were joking, then I fully agree with you, but I can't tell if you think there is a serious chance of this ;)
– Luc
Jul 11 '19 at 13:17
• If your random password generator is generating easy to guess passwords, you may have inadvertently created something very special. Maybe you could get it to write some Shakespeare next? I'm sure it'll generate a few new works. Jul 11 '19 at 14:34
• @Luc By that logic, winning with a lottery ticket numbered 1,2,3,4,5,6 would be "more lucky" than winning with a "random-looking" ticket. After 94 billion years, it's more likely that a particular target string comes up, but that doesn't mean you can rely on it not coming up sooner. Jul 12 '19 at 11:06

If you wanted to do something about it, all you could do (apart from increasing password length) would be to reject passwords beginning with an 'a'. Now you have removed 1/26th of possible passwords, and the attacker can crack the average password 26/25 times quicker.

...and now, the weakest passwords begin with a 'b'. Do we remove these and make 'c' the new weakest first character? You see where this is going.

The other answers have explained well why it doesn't matter, I just wanted to point out that trying to fix this by avoiding certain passwords is absurd.

To add on to the many good answers here, it's worth noting that even where an attacker is using a brute-force attack (which is rare, given all the better options discussed), good tools don't do a sequential brute-force.

For example, the brute-force mode in John the Ripper (which @Tom mentions above) is called Incremental Mode, and although it does cover the entire keyspace, it uses a frequency based model to cover the keyspace in a much more efficient order than a sequential A-Z attack would.

I also remember and older tool called PasswordsPro, which would do a sequential brute-force, but started at the end of the string rather than the start (aaaa, aaab, aaac, etc).