TechGenix and SolarWinds have partnered to provide a fully-functional, free 21-day trial version of SolarWinds ipMonitor, the WindowsNetworking.com Readers' Choice Award Winner for monitoring applications, servers, and network devices to all visitors who join Security Forums. Sign up to Security Forums and get your copy today! Existing members can pick up a copy from the Members Area.
| View previous topic :: View next topic |
| Author |
Message |
PGPhantom
Lurker
Joined: 28 Jul 2004
Posts: 10
|
 Posted: Fri Aug 06, 2004 10:48 pm Post subject: "Cookie" can the hash be cracked? |
 |
|
|
I was informed that it was possible to take cookies off of a computer and using readily available tools, crack the hash value for the passwords? Is this true and if so, what tools are able to do that?
|
|
| Back to top |
|
 |
M3DU54
Trusted SF Member
Joined: 11 May 2002
Posts: 414
Location: Las Palmas de Gran Canaria
|
| Posted: Fri Aug 06, 2004 11:24 pm Post subject: Re: "Cookie" can the hash be cracked? |
|
|
| PGPhantom wrote: |
| I was informed that it was possible to take cookies off of a computer and using readily available tools, crack the hash value for the passwords? Is this true and if so, what tools are able to do that? |
Your best bet for cracking the hash is to find someone who has generated rainbow tables for that particular algorithm. A rainbow table is a list of every password possible (given a character set and maximum length) and and its corresponding calculated hash - These tables are arranged by hash allowing easy lookup.
Of course, for a rainbow table to be successful you would be relying on the password being in the table already (If your password is more than 20 characters long forget it, nobody is likely to have calculated a table that far yet, and if they have it's unlikely to be public) Also, its accepted good practice that you don't calculate a hash from a password alone - its likely to involve a salt which may or may not complicate matters.
I suggest looking for a decent size rainbow table for the algorithm used (If unsure its almost certainly MD5, try that)
Now get googling ; )
M3Dz
|
|
| Back to top |
|
|
PGPhantom
Lurker
Joined: 28 Jul 2004
Posts: 10
|
| Posted: Sat Aug 07, 2004 1:44 am Post subject: |
|
|
If you generate a rainbow table on Alpha - Do it automatically encompass upper and lower case or must you create a separate table for each?
Are there any discussions that you know of pertaining to rainbow tables as I did not find any - Unless, I am just looking in the wrong places 
|
|
| Back to top |
|
|
M3DU54
Trusted SF Member
Joined: 11 May 2002
Posts: 414
Location: Las Palmas de Gran Canaria
|
| Posted: Sat Aug 07, 2004 2:07 am Post subject: |
|
|
You can use any range of characters you wish, the larger this range the longer it will take to generate the tables.
I'd *strongly* suggest using an online lookup rather than trying to generate your own table. The largest rainbow table for MD5 (that I am aware of) is around 75gb, the largest public tables that I've seen are around 50gb...
With this in mind you will appreciate that generating your own is going to be rather time intensive even on a high performance cluster and quite redundant to boot.
http://www.security-forums.com/forum/viewtopic.php?t=16693
http://www.rainbowcrack.com/
M3Dz
|
|
| Back to top |
|
|
PGPhantom
Lurker
Joined: 28 Jul 2004
Posts: 10
|
| Posted: Sat Aug 07, 2004 6:24 am Post subject: Thank you ... |
|
|
I read the topics you suggested - Very informative. I assume, for sescurity, that Microsoft has made cookie hashes MD5 and not LM? From reading other posts it appears that MD5 is certainly the way to go and anything over 14 characters is pretty much near impossible to hack, even with large rainbow tables.
But ... Why would a person chose to use the rainbow utility over LC5, except maybe price. With brute force LC5 can pretty much get most passwords.
|
|
| Back to top |
|
|
M3DU54
Trusted SF Member
Joined: 11 May 2002
Posts: 414
Location: Las Palmas de Gran Canaria
|
| Posted: Sat Aug 07, 2004 5:15 pm Post subject: Re: Thank you ... |
|
|
| PGPhantom wrote: |
| But ... Why would a person chose to use the rainbow utility over LC5, except maybe price. With brute force LC5 can pretty much get most passwords. |
- Dictionary based attacks take some time with no garauntee.
- Hybrid dictionary takes a long time with no garauntee.
- Brute forcing takes considerable time but will find any password EVENTUALY provided that it fits within the character set chosen.
- Creating a rainbow table takes considerable time but is reusable.
- Re-using a public rainbow table is FAST and takes advantage of the previous precalculation of others.
You ask why use a rainbow table when you can use brute force
A rainbow table IS a brute-force, it has simply been saved to disk and reused rather than discarded - This makes a massive saving on computation time. If you're on a single machine and the hash is NOT found by the rainbow table then you're very unlikely to get it by brute-forcing from where the rainbow table leaves off.
However, if you DO try to brute force from where a rainbow table ends please do it by creating a new rainbow table and searching against it ... you can then submit it to the project thus strengthening the public tables for others. Try rainbowcrack.
| PGPhantom wrote: |
| From reading other posts it appears that MD5 is certainly the way to go and anything over 14 characters is pretty much near impossible to hack, even with large rainbow tables. |
Not impossible. Just very very VERY time consuming <G> You 'may' hit a collision early and, whilst this won't reveal THE password, it will reveal a string of garbage which may be equally effective AS a password.
Back in the old dialup BBS days some BBS software used to save user passwords as their CRC32. The problem with this was that collisions were trivially found, although you couldn't get the users password you could quickly generate hundreds of short strings that would also get you in, and that was on an 8086 running 10Mhz. Finding such a collision in MD5, a 128bit one-way hash) is also possible due to the compression function. But its FAR less likely than those old CRC32's.
I'm not saying that you're likely to get anywhere with this, you're not ; ) But that certainly doesn't mean you shouldn't try. Even though a sensible password+salt is unlikely to be in the table, the larger the table gets the more collisions there will be.
The point to remember is that none of these methods exploit a weakness in the MD5 algorithm, but rather a weakness in the password/salt used to generate the hash.
M3Dz
|
|
| Back to top |
|
|
JustinT
Trusted SF Member
Joined: 17 Apr 2003
Posts: 1233
Location: Charlotte, NC, US / Uberlāndia, MG, Brazil
|
| Posted: Sat Aug 07, 2004 9:53 pm Post subject: MD5, rainbow tables, and things. |
|
|
MD5 is not "the way to go", security-wise, and hasn't been for quite some time, for two primary reasons: We advocate 128-bit levels of security; MD5's 128-bit output value exhibits a complexity of 2^64, which is far below what we advocate. The compression function of a hash function should be sufficiently robust; MD5's compression function is rather fragile. If you want a route that's "the way to go", conservatively, you'll be much better of with a hash function such as SHA-256, which roughly meets our 128-bit security level design goal and sports a cryptographically appealing structure.
To echo the above, consider some opinions on MD5 and susceptibility to collision-based cryptanalysis, with mention of notable cryptanalysts and their research:
| JustinT wrote: |
Of course we know about pseudo-collisions on the compression function of MD5; we even know about collisions on the compression function of MD5, as well. We've briefly discussed this in the past (our forum search function exists for a good reason), and noted the most significant cryptanalyses, within the last decade, such as those by Dobbertin, den Boer and Bosselaers, and van Oorschot and Wiener. Dobbertin, of the German Information Security Agency, circa mid-1996, published monumental results, outlining collisions that could be performed in around 10 hours on an average PC, back then. Be sure to follow links to other threads and papers, at the above link, as you'll be able to read a little more about hash function design methodology and the impact this analysis has on its philosophy; a good example of this can be found in the November 12th, 1996 (Dobbertin) and Summer 1996 (Robshaw) editions of RSA's publication bulletins and notes.
When you consider the composition of what constitutes a good, cryptographically secure hash function, these analyses are rather devastating to MD5, and worth a note of caution to other modern hash functions based on the internal structures of MD4. The design of such functions is among the most arcane and difficult of cryptographic research.
The results are not to be taken lightly, in any extent.
|
Some various thoughts on rainbow tables and chains, along with specific cryptanalysts that can be investigated for further detail on time-memory tradeoff-based attack methodology:
| Justin wrote: |
Rainbow tables and chains are quite interesting. Don't confuse it with a specific attack on MD5, as it's rather general, and applicable to most any one-way hash function construct, essentially. On top of that, its concept is closely related to that of specialized exhaustive searching, such as the common, yet insanely effective, dictionary attack. It's when you specialize the form of this approach, that it becomes more feasible, cost-wise. As such, you'll notice that this methodology has been utilized successfully, in practice, in certain scenarios, where poor etiquette in cryptographic parameters was tolerated.
The idea of using such "rainbow" tables and chains is that precomputation, along with lowered complexities of both online processing during exhaustive search and memory during a table lookup, makes for a more efficient way to perform a time-memory tradeoff, which is essentially what a rainbow table and chain boils down to, in definition, and the context for which an exhaustive search technique is deployed. The idea has been toyed with, for decades, and you can easily research this, by checking out the works of time-memory tradeoff cryptanalysis, by cryptographers such as Hellman, Borst, Vandewalle, Preneel, Denning, Kim, Matsumoto, Fiat, Naor, Kusuda, Standaert, Rouvroy, Legat, Quisquater, van Oorschot, Wiener, Oechslin, Delescaille, et cetera. I'd have to say, the approach it takes is about as trivial to cryptanalyze as it gets, and among the most efficient of the time-memory tradeoffs - provided you can afford the precomputation, which in practice, requires an enormous memory overhead.
Nonetheless, it's an effective cryptanalytical venture, and holds a kin efficiency like that of a dictionary attack, so I'd expect to see more practicality out of this, as the required computing resources become more of a tangible commodity to the public community. It's all resting on the "if" statement, for now, until we can comfortably handle conventionally accepted, large cryptographic values in negligible time and workloads.
|
In all honesty, the hash function will be the lesser worry; insanely poor password and passphrase choosing values, equally-as-poor password-to-cryptographic-key derivation, and lax storage methodologies will pose much more realistic threats. Being responsible is addressing each of these issues equally, and making sure a sufficient hash function is sitting in the middle; by sufficient, we mean a structure that is cryptographically secure, that produces an output of at least 256 bits. This means you need to utilize something more robust than MD5 and always recognize the realistic practicalities of collision attack methodology and exhaustive search.
_________________
"Strict Avalanche Criterion n. Restrictive clause in ski-insurance policy."
|
|
| Back to top |
|
|
ShaolinTiger
Forum Fanatic
Joined: 18 Apr 2002
Posts: 2767
Location: Kuala Lumpur, Malaysia
|
| Posted: Mon Aug 09, 2004 4:41 am Post subject: |
|
|
But normally if you have the Cookie hash, you won't bother trying to crack it, just use the hash to generate a valid Cookie for the website, then you have the same access as the user whos details you have.
There are some online rainbow cracking resources though if you're interested:
http://passcracking.com/
http://sarcaprj.wayreth.eu.org/
_________________
Share your knowledge, it's a
way to achieve Immortality.
Quit Smoking - Darknet Hacking
Kung-Fu Geekery
|
|
| Back to top |
|
|
ports
Just Arrived
Joined: 23 Apr 2004
Posts: 3
|
| Posted: Mon Aug 09, 2004 9:57 pm Post subject: |
|
|
| M3DU54 wrote: |
I'd *strongly* suggest using an online lookup rather than trying to generate your own table. The largest rainbow table for MD5 (that I am aware of) is around 75gb, the largest public tables that I've seen are around 50gb...
|
Do you know something about the charlenght, characters used and the
success probability? I 'just' know a set of 250 tables with about 160GB
using max 7, mixalpha-numeric-symbol14 (and space) with a success
probability of 99%.
| M3DU54 wrote: |
With this in mind you will appreciate that generating your own is going to be rather time intensive even on a high performance cluster and quite redundant to boot.
|
Time consuming is quite understatement
ports
|
|
| Back to top |
|
|
M3DU54
Trusted SF Member
Joined: 11 May 2002
Posts: 414
Location: Las Palmas de Gran Canaria
|
| Posted: Mon Aug 09, 2004 11:55 pm Post subject: |
|
|
| ports wrote: |
| M3DU54 wrote: |
I'd *strongly* suggest using an online lookup rather than trying to generate your own table. The largest rainbow table for MD5 (that I am aware of) is around 75gb, the largest public tables that I've seen are around 50gb...
|
Do you know something about the charlenght, characters used and the
success probability? I 'just' know a set of 250 tables with about 160GB
using max 7, mixalpha-numeric-symbol14 (and space) with a success
probability of 99%. |
The public searchable in question is loweralpha-numeric[8] with 80 tables of 610mb at 47.6gb with 99.56%. The largest private table I've seen on offer is around 75mb. Personally thats all I have seen available publicly or for private purchase/searches. Obviously you can generate tables to any size and set you wish but my advice was to search an existing public table and pray for an unlikely collision.
If you know of a 160gb mixalpha-numeric-symbol14+space[7] available then please post the contact details, if known, and/or the format it comes in.
| ports wrote: |
| M3DU54 wrote: |
With this in mind you will appreciate that generating your own is going to be rather time intensive even on a high performance cluster and quite redundant to boot.
|
Time consuming is quite understatement :) |
Indeed.
However neccessary in cases. Regarding large salts the only real option may be to create your own salt-specific DB in order to find a particular password which would take a lot of time and processing power - but is by no means impossible. Especially if one is a cluster nut. At least it removes the entropy of the salt and leaves you dealing with the password alone.
M3Dz
|
|
| Back to top |
|
|
ports
Just Arrived
Joined: 23 Apr 2004
Posts: 3
|
| Posted: Tue Aug 10, 2004 8:55 am Post subject: |
|
|
| M3DU54 wrote: |
| ports wrote: |
Do you know something about the charlenght, characters used and the
success probability? I 'just' know a set of 250 tables with about 160GB
using max 7, mixalpha-numeric-symbol14 (and space) with a success
probability of 99%. |
The public searchable in question is loweralpha-numeric[8] with 80 tables of 610mb at 47.6gb with 99.56%. The largest private table I've seen on offer is around 75mb. Personally thats all I have seen available publicly or for private purchase/searches. Obviously you can generate tables to any size and set you wish but my advice was to search an existing public table and pray for an unlikely collision.
|
Ah, sounds like the table posted at full-disclosure (or bugtraq, can't remember it).
| M3DU54 wrote: |
If you know of a 160gb mixalpha-numeric-symbol14+space[7] available then please post the contact details, if known, and/or the format it comes in.
|
The table isn't available to the public at the moment.
| M3DU54 wrote: |
| ports wrote: |
Time consuming is quite understatement |
Indeed.
However neccessary in cases. Regarding large salts the only real option may be to create your own salt-specific DB in order to find a particular password which would take a lot of time and processing power - but is by no means impossible. Especially if one is a cluster nut. At least it removes the entropy of the salt and leaves you dealing with the password alone.
|
I never tried it, but I would assume that's quite hard to find a MD5
password with a 48bit salt. DES with a 16bit salt seems to me more able
to do  It's not only a question of time. It's also a question of
storage you need for all the files.
ports
|
|
| Back to top |
|
|
|
