# Understanding brute-forcing algorithms [duplicate]

I've been reading up on brute-forcing techniques and possible methods of prevention, but there is one issue that I haven't been able to find a clear answer to.

The way I understand it, a 'simple' brute-forcing attack for a password with 4 numbers would start with 0000, then 0001, 0002, etc. etc.

In theory, then, can you assume that if 0000 takes 1 second (just to keep things simple), and 0001 takes 2 seconds; then 9999 would take 9999 seconds?

Based on this, it would seem that --for example-- if you set your PIN code to 9999, it would take 9 times longer to crack than 1111?

Of course, this is an over-simplified example, but if we were talking alphanumeric passwords with symbols, wouldn't the safest password theoretically be a combination of the highest numbers, highest letters, and highest ASCII values for symbols?

I hope the question is comprehensible and someone can shed some light on this issue for me.

## marked as duplicate by Anders, Celeritas, WhiteWinterWolf, Matthew, Steffen UllrichJun 15 '16 at 21:32

• Yes, that's right. But just a single brute-force program somewhere in the world makes them practically weakest combinations. – techraf Jun 15 '16 at 2:22
• It's like making an assumption: if a brute-force engine would start with 4-digit numbers, then 5-digit, 6, 7... Then a combination of 3 digits is theoretically the safest. – techraf Jun 15 '16 at 2:25
• Sure, but there's no reason to think you try the brute force passwords in any particular sequential order. If you were brute forcing all 10000 passwords between 0000-9999, you could try every p-th password cyclicly as long as gcd(p,10000) = 1. E.g., let p = 33; if you started at `0000`, you'd next try, 0033, 0066, 0099, 0132, ... 9966, 9999, 0032, 0065, ... and `0001` would be the absolute last password you'd try. If you have a N-character long password with d possible characters for each digit, then there are d^N passwords, and you could try every p-th password as long as gcd(p,d^N) = 1. – dr jimbob Jun 15 '16 at 5:02
• But more over when analyzing a passwords strength, you should think of the independent random choices made to make it (how many passwords could be constructed from those random choices). You shouldn't worry if your password starts with an `A` or `z`, where your password will only be stronger against one particular order of brute-forcing (and weaker against other sorts of ordering like going backwards from the end or starting N threads from points splitting the data into N distinct groups) or patterns that take strides (like my previous example). – dr jimbob Jun 15 '16 at 5:07
• At least Related – print x div 0 Jun 15 '16 at 6:46

Any practical brute-force algorithm will take into account the method a password was generated with.

• If a password was randomly generated. You should assume brute-force algorithm also to be truly random. You don't know what it is, you can't claim one password is faster to find than the other, you can only tell that on average passwords would be discovered by checking half of the available pool.

• In case of a password known to be generated using a random number generator with a vulnerability (some numbers more likely, some impossible), an attacker will modify the brute-force algorithm accordingly.

• If it is known that passwords are human-selected (a type of weakness in the generating algorithm), an attacker will use methods applicable for such weakness including: common words, substitutions, repetitions, inclinations, order reversal, known methods, tips, tricks, padding, etc.

It's a human mind vs human mind contest. Sequential checking is statistically least effective and drawing conclusions about a given password strength based on the assumption that an opponent will use the least effective method is a fallacy.

To attack a vulnerability of human-generated password, one might use sociology (some passwords methods seem cooler than the other in respective population). Another attacker might use statistics (take millions of leaked password, analyse, apply). Yet another might consider mechanics (keys and key combinations easier to type on a certain device would be tested first).

In an example of a 4-digit number, I would start guessing with `1999`, go down to `1900` before testing `2000` - `2016`. Definitely I would check `9978` long before `6853` (really inconvenient to type on a PC keyboard) and `5683` (well known "love") long before the two. Someone informed might use more effective method (yes this is an exampleーthe one used in the questionーplease use it to draw a general conclusion, not to dispute the example).

• I saw a distribution on the net earlier this year, taken from a real-world breach. Of all four-digit numbers, 1234 was the most common, followed by 1111, then the 1900s; and the next-best choices were 2222, 3333, ..., 9999. – Alexander Jun 15 '16 at 8:23
• That's the point. You would brute-force using your method based on statistics. I would use mine. Someone else would go from 0000 to 9999. A person who chooses password has no way of knowing. – techraf Jun 15 '16 at 8:28
• @Alexander Maybe this one? datagenetics.com/blog/september32012 – Anders Jun 15 '16 at 9:01
• Also: first pair of digits in [01,31] and second pair in [01,12] would catch a lot in ~37% of the character space, if human-generated. – Chris H Jun 15 '16 at 13:02
• @ChrisH Aye, should have thought it through. All possible birth dates are, of course, exactly 3.66%. Including the reversed format suggested by Nzall brings it up to 5.88%. – Alexander Kosubek Jun 15 '16 at 15:18