Information Security Stack Exchange is a question and answer site for information security professionals. It only takes a minute to sign up.
Sign up to join this community
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?
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).
Most passwords are still weak (say, your dog's name, plus maybe your date of birth, etc.) and the attackers don't like wasting too much time, let alone years to crack passwords. So what attackers normally do is use dictionaries and patterns. They will first try passwords like: pass123, 123pass, john90, john91, John92, JOHN93, 123456, l1nux4dm1n, etc. If every attempt with dictionaries and patterns fails, they might move on and assume that the password looks truly random. How long will it take to try all the possible passwords? If that can be done in a reasonable time, they might try them all (for example from aaaaaaaa to 99999999). Otherwise if the attacker assumes that they will never be able to try them all, they might try to bruteforce the password with some random guesses (random strings, not ordered): 12hrisn589sjlf, 9f2jcvew85hdye, otnwc739vhe82b, etc. If the attacker is lucky they might find the password, sooner or later. However if the password is too strong, such that it would take them too many years to guess it, they had better give up or think of an alternative attack (phishing, shoulder surfing, keyloggers, etc.)
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.
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.
aaSo, 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.
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.
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.
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:
In this case it would probably be good to make the 'a' 1% less likely
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.
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.
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).
