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.."
Of course, If it builds a database of results and checks this cache before attempting the hash directly..... Quite scary, really.... Like building an automatic database of common passwords and their hashes.....
on page 2 when results are 500, you'll find
;)
"f3789b3c1be47758203f9e8a4d8c6a2a" = "goatse"
So stop submitting it!
There are already md5 cracking utilities out there that are extremely fast. It'd probably be faster to brute force the hash on your own machine, really.
Now, distributed md5 cracking would be quite interesting.
Pardon me for actually checking out the site. It seems as though you don't submit an entire shadow file after all. Only the hash of the password.
http://www.rootstrikers.org/
/boot/kernel init=/bin/bah ....[wait here]
bash# passwd
New UNIX password: .. Takes a minute or so...
is what this is. MD5 is not a reversible algorithm. There is no way, even in principle, to go from a hashed result to retrieve the input. An infinite number of letter/number combinations could be used to produce any given MD5 hash. At best, they could come up with a combination that produces the same hash as the one given to them, but that does not mean it is the right answer. And they have virtually no chance of cracking a hash made from a well-selected password.
"At the moment we can crack md5 hashes in this character range: a-z;0-9 [8] which means we can break almost all hashes (99.56%) which are created from lowercase plaintext with letters and/or digits up to length of 8 characters." (Emphasis mine)
If your password is under 8 characters and contains only lowercase letters and digits, you deserve to be cracked.
If you use a proper password, then you have nothing to fear from this "service"
Goatse does exist. Just that goatse.cx doesn't exist anymore. Try googling for goatse's mirrors...if not, let me know, I'll mail you those pics + tub girl + final solution - yep, I got 'em all :-)
On Solaris Sytems (and probably others, but I only know for sure about Solaris) you have two files containing user/login information. /etc/passwd has most of that information, such as login name, actual name, home directory, login shell, etc. Any user can read the contents of /etc/passwd.
The shadow file contains the login name, the hashed password, and some other stuff that I don't recall. This file is readable by root only.
William of Ockham had no beard. The most likely explanation is that it was chewed off by squirrels every morning.
the funny thing is you guys thought I was serious.. cant you tell a little joke ?? :)
Nick D
This is probably obvious, but you can verify it using:
$ echo -n goatse | md5sum
f3789b3c1be47758203f9e8a4d8c6a2a -
So parent is right.
There is no publically known MD5 hash collision. While it's rumored that one or more is known, it's never been confirmed. While MD5 is thought to be weaker than SHA-1, saying that MD5 has a "vulnerability" is going a bit too far.
that can be changed, it'll just take a lot more space for them. For those that didn't RTFA. What the rainbowcrack system is is a system that generates all the hashes for a known keyspace. Then all that is needed is a lookup in these (gigantic) tables.
A click-through license is not a binding contract. In fact, it is absolutely nothing, legally. Yes, EULA's are worthless pieces of text as well, and shown unenforceable in court.
Just so that its clear, they haven't broken MD5 in the cryptographic sense; they're merely using the fact that the 8 character password space is small enough if you are restricted to lowercase alphabets and numbers (about 3*10^12) to run the whole thing through a brute force search. The nice thing is that they precompute all the plaintext-ciphertext pairs, which means that the actual cracking step is simply a lookup. Lookup can be greatly speeded up if you're looking up lots of things at once, so the /. effect is a very good thing for them, throughput-wise :-)
In the old days, you just had a world readable /etc/passwd. It had to be world readable because that was where all the uid username, uid home directory, etc. lookups got their data from. this left the passwords, though encrypted, world readable. Passwords are a one-way hash algorithm, so the only way to break a password is to guess something, encrypt it, and see if it matches. In theory, very hard to break. In practice, people severly limit the possible password space to search (how many passwords do you have that have your name, even though you know you shouldn't) so it reduces the amount to passwords you have to try.
/etc/passwd file kept most of the info, but a file, readable only by root, kept the encrypted passwords. This is /etc/shadow. It has the username, password, and nowadays some password meta-information, like aging, etc.
/etc/shadow isn't as much of a security aid, since most people need to have logins on many machines, and the encrypted passwords are generally available (NIS, LDAP) from the server anyway. I freaked once in my dotcon daze when I found we had a root equiv account with no password, because the "skilled sysadmin" we hired couldn't remember passwords. My CEO, trying to justify this guy (essentially justifying his hiring an idiot) said "well, not having a password is unexpected, just like a good password". I thought 1) I found out, easily, without guessing and 2) justifying something by saying "no one will guess this because no one will think we're this stupid" isn't good justification.
This got changed a long time ago to where the
His statement basically is "did you forget your password, but still have it available, encrypted." It's semi-coded for "hey, wanna crack someone's MD5 based password, if you have it, we can crack it"
Nowadays,
The only thing that makes this remotely feasible is the limited character set and the length limit, which puts the total possible combinations it looks through at about 2.9 trillion. If they were to use uppercase letters as well, the total number of possibilities becomes about 222 trillion, and the search would take a lot longer.
Any system which still stores the hashed passwords in /etc/passwd is almost certainly so old that (a) it has 10,000 other known attack paths and (b) doesn't use MD5 for its hashes.
"that's not encryption - it's a new perl script that I'm working on..." - from some Matrix parody
Why not just use the method that crypt() uses, and use a salt? It's not terribly difficult to implement, and it would mean their database would need to be roughly 3,800 times as big as it is now ( assuming [a-zA-Z0-9]{2} ) Since they have 47.6 GB of lookup tables now, adding a salt would mean the resulting database would be over 180 terabytes.
Not to mention adding in special chars and uppercase letters, which would increase the database by 600 fold, assuming it's linear...
Have you tried this yourself?
/bin/sh or /bin/bash, /bin/bah wouldn't work. It is a good idea to remount the filesystem read only again after changing the password. Then you can reboot or type exec /sbin/init.
I have tried it once, and it does in fact work. (Not that I would have needed to try it, I knew it would work).
I am curious about filesystems being mounted and such when you do this.
There is one detail you must remember. The root filesystem is normally mounted read only if you follow the example, so you would have to remount it read/write before trying to change the password. Or you could just add rw to the boot command. Of course you have to type
You can prevent all of this by protecting your bootloader with a password, such that you cannot change the boot command without providing a password. Of course booting from an alternate media is still an option. To prevent that you could change your BIOS configuration, and weld the case to prevent anybody from resetting your CMOS. (If you just need to protect confidential information on the HD, encryption would be a better solution).
Do you care about the security of your wireless mouse?
As long as you aren't using passwords that are straight out of the dictionary (this is like 3rd grade people) you should be fine even with something like this being available. I suggest quit using passwords, and use passphrases instead. Someone MD5ing phrases will have to look for months not days.. Change your passphrase like every three months and you'll never have a thing to worry about. The only problem is that md5 has a pretty limited key space and "foo" might equal "TheLastStand" so someone may come up with an equivalent key. Regardless, md5 is designed to keep people from being able to easily come up with these passwords or alter a file it is not designed to keep people off of your computer and it is still much better than crypt. Being able to reverse an md5sum isn't going to get someone on your system that hasn't already got in. Make sure root cannot log on to your box and a user cannot su without being in wheel so if someone does crack the md5 they have no hope of getting any more rights than they already have. Configure a script to run to alert you right away if someone attempts to su but gets canned because of not being in the wheel group. Really stuff unix people should have been doing all along
Remember: Don't Panic!
-Mind
You have access to the shadow file, but you can't remember your password, so what do you do?
Submit the hashes over the internet of course!!
What the hell were these people thinking? If you have access to the shadow file, then you have root access, and you can just passwd a different password. Root doesn't have to supply the current password.
Worst case scenario, just cut out the hash and it'll be a blank password until you reset it. And if you really need that password, odds are that the others in there would be a nice bonus too, in which case there's plenty of other tools available.
It is a time-memory tradeoff. They come up with a "reduction function" R, which maps hashes into keys. It is not a reversal of the md5 algorithm, it just generates some key based on the hash. Then they create sequences of hash, key, hash, key, hash, key... with each key being the reduction function applied to the previous hash, and each hash being the hash function applied to the previous key. They stop their sequences when they reach "distinguished values," which may e.g. have 0's for the first 12 bits. Then they store the start and endpoints of the sequence.
So now they have a list of start and endpoints for these chains of hashes and keys. To crack a hash, they apply the same process to it - reduction function, hash, reduction function, hash, until they reach a value that is in their table of endpoints. Then they begin at the startpoint associated with that endpoint, and regenerate the sequence up to the hash they're trying to crack. Since the key directly before that hash hashes to that hash, they've successfully cracked the hash.
The "rainbow" refers to the recent innovation of using a different reduction function for each step of the sequence, i.e. using R1 on the first hash, R2 on the second, etc. This means that, even if two sequences contain the same hash, they probably won't be exactly the same after that - a significant problem with the older method of having a single reduction function.
If you want to read about this in more detail with math symbols and such, the pdf is linked from the site.
you dont get the same has from two different passwords. when you log in, your computer doesnt actually compare passwords, it compares the hash of the password you just entered to the hash of the previously stored password. This is why ROOT can't recover your password, and can only change it (unless they submit to this site, that is...)
if you could get the same hash from two different passwords, then you would have multiple passwords for every user on most Linux/Unix computers. The 42 answer was a joke, a movie reference. I forget the exact movie, but I remember the guy asked "what is the meaning of life" and the answer was 42. Problem being he didn't know the question it was calculated from. You had to be there I guess.
Tequila: It's not just for breakfast anymore!
Anyway, time to change up to SHA1 ;)
/^[A-Z0-9._%+-]+@[A-Z0-9.-]+\.[A-Z]{2,4}$/i
Yes, because knowing the password means that you automatically know the IP address too, right?
Um, YES. You obviously have never admin'ed an apache web server. By default, it logs every IP, every request,
Yeah, a 47GB app. That'd be a snap to download.
Its not a 47GB app. The source is 44k, and the compiled binary is well under 1mb. If you bothered to check you would know that. That has nothing to do with the resources it uses when it is cranking.
Tequila: It's not just for breakfast anymore!
17:25 http://passcracking.com/
:)
17:25 <ge_> !!
17:26 <toast> interesting
17:26 <toast> let's DoS it
17:26 <ge_> hehehehe
17:26 <toast> just write a distributed tool to submit nonsense and keep the queue full
17:26 <ge_> worse
17:26 <ge_> let's slashdot it!
17:27 <toast> haha
17:27 <toast> perfect
- "When you want something with all your heart, the entire universe conspires to give it to you" -Paulo Coelho
Also, one hash maps to infinitely many unique items. Read up on the pigeonhole principle. The short form is that there are only 2^128 md5 hashes, so if there are more than 2^128 things which can be hashed (and there are) then more than one of those will map onto the same md5 hash. Granted, at least one of the passwords will have to be longer than 16 bytes and it'll be likely to have non-printable or high-ASCII/UTF-8/whatever garbage in it, but it's still possible.
(And, the converse is that no matter how long your password is, there'll always be a 16-character string which is equivalent to it.)
There are 10 kinds of people: ones who understand ternary, ones who don't, and ones who think this joke is about binary
How long does it take to compute an MD5 Sum?
Approximately 30 cpu cycles per byte, rounded up to a block size of 16 bytes, I think. That's assuming you can't vectorize the operations easily. That suggests that an average consumer system could generate the table for this project in approximately a week. Vectorize that correctly and you can probably halve it.
It may be that only one sync is necessary to get the data to the disk.
:^)
But since I've heard many times that on some systems, the first sync merely schedules dirty pages for writing, while the second sync won't return until the first sync has completed (buffers actually flushed), I've always gone for the safer bet.
Syncing three times is also a popular way of doing it. I've also noticed that the number of syncs I perform before reboot -f'ing correlates to the amount of coffee I've had.
Alternately, one could simply count to five or so before entering the "reboot" command/hitting the reset switch/whatever, but that's less reliable than muscle memory.
Mashed potatoes can be your friends!
AKA d41d8cd98f00b204e9800998ecf8427e
Its where you password hashes (stored versions of passwords) live these days. /etc/passwd just stores user properties, but not the password hashes. It did once (hence the name), but since everyone on a Unix box can read the passwd file (so users can find each others home directories, for example) they could read the hashes too. With enough time and computing power, they could work out what the typed-in password were from the hashes.
/etc/passwd /etc/users, and /etc/shadow /etc/passhashes, that'd be nice.
If we could rename
IIRC, MD5 was based on the idea that even if two or more things had the same MD5 sum, there wouldn't be more than one *intelligible* or *usable* thing with the same MD5.
That's why MD5 works well for error or tampering verification. You might be able to get a big pile of garbage to have the same MD5 as the real message, but you'd be hard-pressed to create any other legible/interpretable data, or wind up with corrupted (slightly different) data with the same hash.
Information wants to be free.
Entertainment wants to be paid.
You just want to be cheap.
The "salt" is used to change how the password is hashed. If you look at the shadow password file on your computer, you'll see some lines that look like this
root:$1$abcdefge$abcd1234efg789hijklmno:0:0:...
You'll notice that the password field (the stuff after the 1st colon, and before the 2nd colon) is itself divided into 3 fields separated by dollar signs. The purpose of these fields are:
1st field - Identifies hashing method. This allows for future changes to how the password in stored while allowing backward compatability with existing passwords.
2nd field - This contains the salt used to hash the password. In order to verify a new password, this exact salt must be used in the hashing process. Since in this case, it's 8 characters long and each character can be one of 64 values, it means that each possible password my be hashed into one of 2^48 different values. This salt is generated randomly at the time that you set your password. The randomly generated salt is then stored here for use in verifying future authencation attempts.
3rd field - This is the actual hashed password using the salt specified in the previous field. It is 22 characters long, which with base 64 encoding can store 132 bits. Since MD5 only hashes to 128 bits, there are 4 unused bits at the tail end of this value.