Password Cracker(s) that can handle >8 chars?

[genXer]

ok - i'm stuck on this one. for our password cracking while pen-testing, we use LC5 - however i just obtained password hashes that we have found out are 17 characters in length - we just asked the auditee to find out - because LC5 was reporting that the LM String was *empty*. i have not had to use John or Cain, or others in awhile (so i'm a loser, but i want to be a whiner, i mean winner - heh), but has anyone had success with those, or other tools against longer password hashes?

heading off to re-learn about John and Cain.

for those who don't know anything about John, Cain or others:

http://en.wikipedia.org/wiki/Passwor...cking_programs

tia - for your time and repsonse(s).

[NeuTron]

Even if the utility supported it....do you really have enough hardware to bruteforce a 17 character password?

[nihil]

Well,

Firstly let me state that I have never actually tried it on long passwords as I don't do penetration testing for a living. I have used cracking tools in demonstrations/presentations regarding password security though. Not quite what you want, but I believe that the underlying principles are the same.

A lot of tools, you will have noticed, have a cut off of either 8 characters or 14. I believe because 8 used to be a sort of standard, and 14 was certainly the maximum for a Windows 9x environment.

Obviously if your tool or dictionary tables do not support a particular size, you are SOL.

With NT systems you can have 127 characters, which would take an unrealistic amount of time. I suspect that 17 would be unrealistic to bruteforce as well, although I have never personally tried it. Colleagues have reported that they gave up on long passwords due to the amount of time it took without a result.

Naturally a lot depends on the strength of the algorithm. I believe that if you use the weakest WiFi system, you are recommended to have a password of 20 characters?

I would suggest that you look into using the precomputed "rainbow tables" method. I have seen 14 character ones demonstrated and they are fast, but they are VERY LARGE like the straight keyboard was 60Gb, for 14 characters. I shudder to think what the full ASCII set and 127 characters would be

I am afraid that I cannot help much more than suggest that you look into the rainbow tables angle.

My approach is to keep an eye on what cracking tools are readily available and what their limits are. I would then deploy a mechanism to enforce a password policy that is beyond those limits.

//off topic

You will hear people say that long passwords aren't practical, as people just forget them or write them down, which produces local insecurity. People can generally remember 8 characters quite easily, and longer ones if they are broken down like telephone numbers, NATO IDENT numbers and the like.

My psychological take is that people can remember a sequence of actions far better than data........a bit like driving an automobile?

So, if you have a core "password", all you need to do is "pack" it with a sequence of easily remembered keystrokes. For example:

¬!"£$%^&*()_+#PaSsWoRd#=-0987654321`

is a 36 character pass with an 8 character core. The "packing" is the top row of the keyboard left to right with "shift" on, followed by the same row right to left with "shift" off.

I think that John and Cain would have quite some fun with that?

Just a thought



EDIT:

This link might be of interest:

http://www.lockdown.co.uk/?pg=combi&s=articles

[HTRegz]

Hey Hey,

When you find a 17 character password... you walk away...

I'm sure that LC5 will do passwords of 17-characters in length without a problem.. The reason the LM has is being reported as empty is because of a 14 character limit in LM... Technically any admin worth their salt would disable the use of LM hash storage, so using LM in a pen test prolly isn't the greatest idea (Then again, most admins that frequent this site prolly don't disable it and I'm sure we'll find some that didn't know you could -- if you want to find out more check out http://support.microsoft.com/default...EN-US;q299656&)... As nihil mentioned, rainbow tables are the way to go...

I've seen rainbow tables for LM (Used in LM Auth), NT (used in Kerberos, NTLM and NTLM2 Auth), MD5, etc.... You can get LM tables from http://rainbowtables.shmoo.com/... nihil's numbers were slightly off, but you'll see a full LM hash table with 32 special characters (about the biggest LM set out here) is 42GB..

LM was left in place for legacy machines, as shops begin to roll out newer machines, they don't require continued support for LM... LM had several limitations... a length limit of 14.. it was really 7-character hashes stored together..

I've always felt that password cracking during a pen test is cheating... Password cracking should always be attempted (to ensure that passwords are reasonable), however it should be part of a Security Audit... A lot of pen testers will find a weak password and use it to hop from machine to machine, and never actually point out real vulns in your system... they identify a single point of entry and the rest goes unnoticed until the next pen test 6 months down the road when they need to find another vector because the last attack vector was removed...

You most likely won't find rainbow tables freely available for the type of password you are attempting to crack.... Your best bet (assuming you have the money) is to buy many PCs and cluster them... and start generating your own rainbow tables.... You won't bruteforce the password... The reason for this is that NT Hashes are also known as Unicode hashes... technically there are over 100,000 Unicode characters... Let's assume a more reasonable number of 256 characters.... 17 characters... each one with 256 combinations... so if I'm remembering correctly that's 256 for the first combination, 256 for the second combination, 256 for the third and so on... that's 256 ^ 17, which according to the trusty Windows Calculator is 8.7112285931760246646623899502533e+40. The number is so "low" only because you know it's 17 characters, it'd be quite a bit larger if you had to account for every number of characters... Now it's late so I'm sure my math is off somewhere... but if you could do 1000 passwords / minute.... it'd still take you 1657387479675803779425873278206.5 centuries... so for arguments sake.... let's call that uncrackable...

What is it that's written over the gates of Hell? "Abandon hope all ye who enter here"... I'd say that'd be like trying to crack a 17 character password knowing that it's using Unicode/NT Hashes.

Peace,
HT

[nihil]

Yes UNICODE would be a nightmare, as it is a multilingual multicharacter concept.

Even if you settle for what is on the keyboard and assume English as the language (no weird ASCII characters) it is bad enough. There are 37 characters, 10 numerals and 26 alphas in 2 cases, which gives you a total of 99.

You also "know" that the length is 17 from what you have been told. It would probably wise to assume that there is some mechanism in force to enforce this policy?

You are still going to be faced with an enormous task The size of the tables might be reduced if you only calculate them for 17 characters, but we are not talking LM hashes here.

Obviously, if the hash is salted then the tables won't work.

HT~ has a point:

A lot of pen testers will find a weak password and use it to hop from machine to machine, and never actually point out real vulns in your system

My point would be that part of the security audit should be to ensure that there is a mechanism in place to enforce the password security policy and that it works.

My argument would be that if the system will not allow a weak password then attempting to crack it is a waste of time. Rather, you should consider whether the policy itself is adequate for the risk involved?

Just a few thoughts