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?
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
Hence an executable file with a specific MD5 value either is the original or garbage that won't run.
Don't count on it. When you create an executable it is easy to put 17 bytes somewhere, that is really not used for anything. After this has been done just start searching for a combination of those 17 bytes that produce the expected hash. It is very likely that more than one choice will exist. Of course this would take too much time.
It is easier to produce a collision. Create two executables, and instead of the 17 bytes from before just leave 9 unused bytes in each file. Then try all choices for each of the two files, and sort the results to find your collision. 2*256^9 is way smaller than 256^17. Of course even this is still infeasible. But it will be possible in a few (50) years. Using SHA1 is a bit better, but it will only take about 100000 times as much CPU time to find a SHA1 collision as an MD5 collision. Which means the computer to do it will be available about 25 years later than the one to find an MD5 collision (assuming More's law still holds).
Do you care about the security of your wireless mouse?
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
}
}
}
- 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.