Slashdot Mirror
Online MD5 Cracking Service
toast writes "Did you forget your password but have your /etc/shadow? If so, this site is for you. Submit a MD5 hash and within a few days you'll have an answer. Of course, once Slashdot has its way, you'll have to wait a few years for an answer.. At least now I'll always know what f3789b3c1be47758203f9e8a4d8c6a2a means.."
This is why we use salted, iterated hashing.
What is /etc/shadow?
.. At least now I'll always know what f3789b3c1be47758203f9e8a4d8c6a2a means.
You'll have to keep wondering! While MD5 isn't secure, any non-original byte sequence that produces the same MD5 is likely to be garbage. Hence an executable file with a specific MD5 value either is the original or garbage that won't run. In this sense it's reasonably secure... However, for the RIAA and others, garbage might just be what they need. Thankfully, LimeWire and other P2P apps have been using SHA-1 for a while now, which doesn't have the same vulnerability.
So at my current job, where the guys at the datacenter that "manage" our boxes once a month copy /etc/passwd and /etc/shadow into /tmp to edit them automatically (to maintain their list of 160 people at the datacenter that have root access to our production boxes.. y'know, the guy that runs cables, the guy that sweeps the floors, etc...), and then makes the *world readable* in /tmp, just for shits and grins....
Luckily I've been pusing to remove any users from our box other than those of us with root.. but still have a ways to go. Hey, now all those developers can grab our shadow file and get root access... online, quick and easy!
If you RTFA, it says that it will only hack the following passwords:
a-z;0-9 [8]
This just seems sorta pointless. Many people are ocmplaining about you getting a password for someone else's stuff -- but if they put a capital letter, or any sort of special character, they're safe from this attack. Is there a reason that they didn't add capital letters into the algorithm?
I think my principles are reachin' an all time low
It appears that this only works for hashes that don't use salt, so it wouldn't work for any hashes that are stored in a shadow file.
so, what they are saying is that they can tell me my password if i give them my /etc/shadow. however, that file can't be read, opened, et cetera, unless you are root. so if i had my root password, i could change my user's password anyway... or make a new user and copy all my ~ files over.
If I didn't have my root password, but had my user with sudo, I could fix it. Or I could reboot into single user mode.
All things which can be done for FREE and without fear of the decrypted password file out in la-la-land with a bunch of h4x0rz? And this fall Fox is going to have a new reality TV show entitled "Orthodontic Surgery, The Final Frontier" where people get root canals for laughs.
The More Laws, the less Justice --Marcus Tullius Cicero
This project is using RainbowCrack technology
Heading on over to the RainbowCrack page, we find (at the bottom):
Contact Information
Zhu Shuanglei shuanglei[at]hotmail.com
Member of Kingnet Security, Inc.
Shanghai, China
Anyone else wonder if this is just a clever way to steal passwords?
The ______ Agenda
I once used a system that had a fairly weak reversible hash for the password, there were in fact several possible passwords that could be computed for any given hash. I changed my password to one that would hash to a typeable string, which was fun since anyone looking in the (equivalent of the) password file would see plaintext. I had my choice of several passwords, I just chose the one which was the least difficult to type. I still remember that password after 20 years.
They did eventually change the hash to a much stronger one after I told them I could crack it. Still, it wasn't that much of a security breach as the hashed password was almost impossible to get to.
Well, 36 ^ 8 = 2,821,109,907,456. How long does it take to compute an MD5 Sum?
More to the point, consider "cracking" passwords in this manner:
The NSA has been reported to have ACRES of computer space; their own chip fab and some of the fastest computers in the world.
What if, decades ago, they just dedicated banks of systems to cracking all possible passwords hashed with crypt. Then, a few years later, did the same thing with MD5, SHA-1, and Blowfish -- as each became available.
They store all this stuff in a table, and now getting passwords to most systems is nothing more than a quick table lookup.
Yes, I know the math. However, add in a bit of psychology and statistics.
Most people don't use characters you can't type on a keyboard for a password. VERY few do ALT-nnn or something like that. Most are going to be puire alpha, or alphanumeric. Some will contain special characters.
Meaning, you don't have to exhaust the entire 8-bit character space to get the vast majority of what you're looking for.
Is it really a surprise that something like this is starting to be possible on consumer systems?
Heck, imagine a beowulf cluster dedicated to this...
Learning HOW to think is more important than learning WHAT to think.
One thing they could do with it is expand dictionary lists. What better way to make a password dictionary than to get a pool of passwords that people actually use?
Same thing for windows users (only different) is here. Submit an LM or NT hash, get the password emailed back to you...
Why sync twice?
Surely just once will flush all data to the hard disk controller buffers, which will then be flushed to the disk surface during the reset that the BIOS will send them during a warm boot?
This is something most people never think about. You actually could have several passwds that work for a given account...anything that hashes to the same thing is a working passwd.
Another neat example of this principle at work is the soundex hash function, which was designed for the US Census to lookup names. It encodes a name such as Johnson as an alphanumerical code J525. Other, similar names, such as Jonsson, Joganson and even Jamieson and Jenkins are converted to J525 as well. In this way, even if people's names are misspelled in some way in the census (or when they were registered at birth; family names tend to evolve over time) they can still be found by a reasonable approximation.
And because the soundex hash is computed when the records are stored, there isn't the kind of overhead that you'd get from a regular expression/glob search over all the records.
The modest computational requirements for what amounts to a very clever phonetic lookup mechanish aren't surprising in a way; Soundex was patented in 1918.
You can play with soundex on this page.
Now imagine your password was stored as a soundex hash.. Ouch! Even if someone looking over your shoulder when you type in your password got half the letters wrong, he'd still get in!
This is exactly why it's so important that cryptographic one-way hashes don't regularly produce the same hash. The name for finding a password that's not the same, but hashes the same is a birthday attack, named after the birthday paradox.
This is the reason why you should salt!
SCO employee? Check out the bounty
#!/usr/bin/perl
M NOPQRSTUVWXYZ';
;
use Digest::MD5;
use constant POSSIBLE_CHARS => 'abcdefghijklmnopqrstuvwxyz0123456789ABCDEFGHIJKL
use constant LAST_POSSIBLE_CHAR => substr(POSSIBLE_CHARS, length(POSSIBLE_CHARS) -1, 1);
use constant FIRST_POSSIBLE_CHAR => substr(POSSIBLE_CHARS, 0, 1);
print "Digest:\t";
$digest = <STDIN>;
chomp($data);
$ctx = Digest::MD5->new;
print "Beginning to decrypt...\n";
$attempts = 0;
$current_string=FIRST_POSSIBLE_CHAR;
$start _time = time();
while($digest ne $attempt)
{
$current_string = next_string($current_string);
$attempts++;
$ctx->reset();
$ctx->add($current_string);
$attempt=$ctx->hexdigest();
}
$end_time = time();
print "String decrypted...\n";
print "String = '$current_string'\t\t\tHash = $attempt\n";
$time_to_complete = $end_time - $start_time;
$seconds = $time_to_complete % 60;
$time_to_complete = ($time_to_complete - $seconds) / 60;
$minutes = $time_to_complete % 60;
$time_to_complete = ($time_to_complete - $minutes) / 60;
$hours = $time_to_complete % 24;
$time_to_complete = ($time_to_complete - $hours) / 24;
$days = $time_to_complete % 7;
foreach $unit (($seconds, $minutes, $hours))
{
if($unit < 10) { $unit = '0' . $unit; }
}
print "String found in $days days, $hours:$minutes:$seconds\t\t\t$attempts cycles\n";
sub next_string
{
($string) = @_;
$last_char_of_string = substr($string, length($string) - 1, 1);
unless( $last_char_of_string eq LAST_POSSIBLE_CHAR )
{
substr($string, length($string) - 1, 1, substr(POSSIBLE_CHARS, ( rindex(POSSIBLE_CHARS, $last_char_of_string) + 1 ), 1));
return $string;
}
else
{
if( (length($string) == 1) && ($string eq LAST_POSSIBLE_CHAR))
{
return FIRST_POSSIBLE_CHAR . FIRST_POSSIBLE_CHAR;
}
else
{
return next_string (substr($string, 0, length($string) - 1) ) . FIRST_POSSIBLE_CHAR
}
}
}
Although someone already replied to this with a rather complex answer, I've seen a few explanations that it's an old UNIX habbit. Basically you sync to the disks once and then again to be SURE that it really synced. I think FreeBSD actually syncs three times automatically as the last step before reboot.
- reboot(8) syncs disks.
- reboot(8) sends TERM signals.
- reboot(8) syncs every 3 seconds for up to 60 while vm.stats.vm.v_swappgsin changes.
- reboot(8) sends KILL signals.
- reboot(2) is called, which calls boot(), which syncs in a loop 20 times, backing off from 1/20th to 1 second while there are active buffers.
- If any active buffers remain, the disk is left mounted so it's fscked next boot.
Now, if only shutdown(8) called sync once, we'd be up to a maximum of 42... maybe I missed one. Nice function name in there at least; die_you_gravy_sucking_pig_dog().You really wanted to know all that didn't you? Hello? Bah.