Date: Wed, 4 Jul 2007 10:12:57 +0100 From: "Larry Bonner" <larry.bonner1@...il.com> To: john-users@...ts.openwall.com Subject: Re: Incremental mode limited to 8 character words? > No, that's not a good reason. Why should it be? because its a simple fact, more people have access to multi-core processing or multiple machines in order to carry out a faster attack against hashes..just think of "zombie" computers installed with a password cracker capable of distributed attacks on hashes. 8 characters is nothing with todays computing power available. A valid reason would be password algorithms and/or > system configurations which force password length > 8, > because then, john's incremental mode wouldn't be > useful. i don't disagree with you, but how many do you know enforce length > 8? sometimes that is the minimum/maximum required length, in order to recover easily. Or, it never gets there. that can apply either way the sequence is computed, i don't see how the order in which its done is any "better" than the other.if they both compute the same strings.. then its only a matter of time. both ways can have advantages, PPro method has its advantage when attacking NTLM1 initially, because of the way MD4 was designed. By only modifying the first byte each time the password string is updated, we have cut md4 processing by almost 50% up to length 10, and further reductions can be made after, by pnly changing the last byte of the password string instead..this works very well in practice. the "shortcut" isn't possible if updating the last byte of the password string from start to end. 1 - 10 AAA BAA CAA 10 - ? AAA AAB AAC You are assuming you will be able to search the complete > key space in a reasonable time. > This is only true for poorly designed password hash > algorithms. but don't you see that you're making assumptions on what constitutes a "weak" password? i am not assuming i can personally search a whole keyspace, but are you assuming somebody else can't? with access to lots of machines? the reality is, there are attackers out there with access to sometimes literally, millions of computers. > Even if you assume you can try one million passwords per > second (which isn't true for many of the algorithms > supported by john), you'll probably not be able to > search the complete key space. again, this is where distributed computing can be applied, break up the keyspace, and compute 1 million or more keys a second.we know it can be done already. it doesn't necessarily have to be done using JTR, plenty of people out there could write their own crackers to do the job just as well. > Assume 95 different characters. > ... > I'm sure almost any password will be of little use > after 210 years. > ... > And if you have salted hashes, you'd have to multiply > the time by the number of different salts. > well, obviously not everyone is going to use all available 95 characters on the keyboard..in fact i can only count about 92 and when i choose a password, its usually made up of just letters/numbers, thats about 62 characters if you consider upper/lowercase combinations. its nice that people have choice of all available characters on keyboard, but truth is most people will likely use characters for a password thats easy to remember..thats where the weakness is usually.not in the algorithm itself, or how many bits the key length can be. so, enforce a good password policy? again, this doesn't happen in real life so much. > Weak passwords are those an attacker can find in a > reasonable time. > All passwords with a length of 3 are weak, IMO. i was giving an example of the way in which PPro creates password strings, not what is a good password length!!! If you can just try a small fraction of the key space, > the order in which you try the candidates becomes important. > What's the point of looking for weak passwords in poorly > designed hash algorithms? whats the point in having password crackers, full stop? what i meant by "poorly designed" is that there are what i term shortcuts. ways to optimize computing a hash to a password by reversing the ciphertext up to a certain point, like you can see in mdcrack source code for md4/md5...or finding the password to a hash through simultaneous encryption/decryption. never thought about doing encryption/decryption at the same time? some might say there is no point, but atleast on archs with lots of registers, you can break up dependencies and increase performance overall. obviously x86 wouldn't be suitable, but x64 might be..
Powered by blists - more mailing lists
Powered by Openwall GNU/*/Linux - Powered by OpenVZ