Gawker (Jalopnik, Gizmodo) Database leaked, 188.000 passwords decrypted

Ah, that's what I missed. I'll blame the early cold morning and let it go at that. I don't use that particular combination of username/password everywhere, thankfully.
 
Luckily I haven't bothered commenting on Jalopnik in ages, same with Gizmodo..which I barely read.

Needless to say, I'm also probably going to delete my account as soon as the option's available, but sent a password reset request to my email in the mean time..as i couldn't remember what password I used in the first place. (maybe i got a password reset before and just didn't bother changing it and commented with the temp password)
 
Torrent on a popular site. Full site rip. If you can't find it, you don't deserve to :p

It's been pulled from TPB but it is out there on a ton of other sites.
 
Well it is a hive of scum and villainy... also hilarity but mostly the scum and villainy bit
 
Just looked and not only was I among the group, but I received an e-mail from someone other than gawker telling me so. Changed my password, it was different from all my others so I'm good. Deleting my account when I can.
 
Anyone else install lastpass after this? :p

Also if anyone's a old school Consumerist (basically when they were still owned by Gawker) commenter, like me, you might need to change your password on Consumerist because when they moved to their own blogging platform, you had to create a new password and many people used their Gawker password.
 
Last edited:
I thought the whole point of a hash was that it's unique, and in this case only points to one password? How else could you get it to work?
Unless you're talking about MD5 (and probably a few others) where you can get the same hash for something different, but that isn't the intended use and the reason why MD5 should be viewed as cracked/unsafe. I don't think DES has that problem?

Ignoring the actual algorithm used, a cryptographic hash function turns some input into a fixed-size bit string. In other words, it maps an infinite number of inputs onto a finite number of outputs - two to the power of size, for a 128bit hash it would be 2^128 or 3.4*10^38 values. As a necessary implication there is an infinitely large number of input values that maps to a single output value.
If they used any hash method then there will be collisions.

Another trouble with hashes is you can pre-compute the rainbow table to look up values, so once you have your leaked password hashes you can immediately use them (obviously, you won't have a complete table - would be ginormous). That is why any simple hash method is a bad idea for passwords, no matter if MD5 or SHA-1 or any other hash. The magic word is salting. Instead of computing the hash value of "password", you take a random number that is unique to that user and stored in plain text in your database, let's say 3652354. Now you compute the hash value of "password-3652354". That way any pre-computed table is mostly worthless, and it would take a long(ish) time from leak to actual abuse of passwords, making the leak less of a problem as long as you notice it. Put simply, instead of computing one table for your entire database, you need one table for every user.
Anyone then stealing your database can not use his precomputed table for regular words, numbers, etc - he needs to start over. As a result, MD5 is considered indeed unsafe for storing passwords - but salted MD5 is not.
 
This guy seems legit.
 
What else is new... it's only gawker accounts not paypal or mastercard. Which I hope most of you use different passwords for both.
 
I'd like to figure out what password was associated with my gawker account. Have downloaded the full_db file. Can you please provide specific instructions for how to decrypt the encrypted password (using php if possible). I am not that familiar with hashes and don't completely follow the discussion in this thread. Specific instructions would be helpful (PM me if you'd rather not publish the instructions publicly-- though you'd have to trust I wouldn't.

I just want to decrypt my own password so I know which one to worry about. Thank you.

Just change all of them.
 
Just change all of them.
I used to have a little text file full of passwords (several dozen completely cryptic ones) on a USB stick that I guarded very jealously. That is, until the day I forgot it plugged into one of the many public computers at uni. :-o I noticed my mistake late in the evening, changed all my passwords and went to the computer hall first thing in the morning - the stick was still there, probably due to it being an ancient 256 MB model whose case keeps falling apart. It was still nice to see that sometimes, a forgotten item may actually not be taken immediately by someone else.
 
You should encrypt that text file. Even if the password is something unsafe as your first name to make sure you never forget it, that's massively better than plain text.
 
You should encrypt that text file. Even if the password is something unsafe as your first name to make sure you never forget it, that's massively better than plain text.
Oh, the stick was emptied as soon as I had it back. Better to be safe than sorry. I now have that file and a couple others in an encrypted .dmg on my laptop. I figured that if I lose my laptop, I'm royally screwed anyway, so if some inaccessible personal info is lost along with it, it won't add to my worries.
 
Ignoring the actual algorithm used, a cryptographic hash function turns some input into a fixed-size bit string. In other words, it maps an infinite number of inputs onto a finite number of outputs - two to the power of size, for a 128bit hash it would be 2^128 or 3.4*10^38 values. As a necessary implication there is an infinitely large number of input values that maps to a single output value.
If they used any hash method then there will be collisions.

Very interesting, I've never thought about it in that way.
In this case with DES they only used the first 8 characters of the password though, and then you have enough possible hashes to cover all the possible inputs, or am i mistaken?
I assume finding the same output hash for different inputs is just as hard as finding the orginal input text then (if the hash method isn't broken)?

bone said:
kip!!! where have you been? i think it's been ages since i last saw you post here?
I've been in the IRC channel and just reading the forums. You've got waaay too many posts :p
 
Very interesting, I've never thought about it in that way.
In this case with DES they only used the first 8 characters of the password though, and then you have enough possible hashes to cover all the possible inputs, or am i mistaken?
I assume finding the same output hash for different inputs is just as hard as finding the orginal input text then (if the hash method isn't broken)?

Whether they have enough hashes or not depends on the size of the hash. Even if the hash is long enough though, chances are high that a collision exists. Let me give you an example: The days in the year are our hash values. Our input is people's date of birth. There are 365 possible hash values, so it should be easy to fit 23 input values into those 365 output values without collision. However, chances are 50/50 that you will get one collision (ie two people out of 23 share their birthday). For 57 people (less than 16% of the hash size) chances of a collision already are over 99%. Simply said, collisions always exist. Do they matter? No. Why? How likely is it that someone attempts to log in to your account not knowing the real password and by chance picks out a password that is not the real one but results in the same hash? Virtually nil. It's much more likely they'll have guessed the real password.

On the second thing, that depends on what you are looking for. If you have one hash value and want to find an input value that produces the same output then yes, finding a collision is just as hard as finding the original string. After all, you do not know the original string - maybe your "collision" actually is the real string? No way to know, because by applying a hash function you lose information - contrary to encryption, that always lets you restore all the info.
That's not the scenario here though, you do not have one hash you want to crack. You have millions of hashes, and want to find as many matching passwords as possible. What you do is simply brute-force through all combinations starting at a, b, c, ..., aa, ab, ... applying the hash function forwards (password in, hash out - runs quickly) and remember every collision you get. Similarly to the birthday problem above, when you have millions of targets it is much much easier to hit some targets. That's why salting is SOOOO IMPORTANT. With a unique salt for every user you turn a tedious computing job into an impossible one. For example, you might compute for a few weeks to get a nice number of cracked passwords, let's say 10000 out of 1000000. With a salt, those few weeks give you a 1% chance of cracking ONE password. In other words, the amount of computing you need to do has just increased by a factor of one million.
 
Last edited:
I've been in the IRC channel and just reading the forums. You've got waaay too many posts :p

especially since i have nothing interesting to say :D

nice to see you back!
 
Top