I think I am going to be checking the dump to ensure my password is not among it…
Remember, don’t use the same password across the Internet. Here’s why.
Edit: It’s there, apparently as a DES hash. …
Update 2: The first two characters are the hash. So if you use a tool like https://hash.online-convert.com/des-generator you are going to put your password in the “Text you want to convert…” box and the first two characters of your hashed password in as the “Salt (optional)”. Then you will see the “Calculated DES Hash” which will be the same as the hashed password from the torrent if you knew or guessed the password correctly.
E.g.
Your Lifehacker password is “hackern”, but in the torrent, it’s just “8h48GPxmwy.EA”. Just to show the torrent is legit, you go to the website I entered above, enter “hackern” and “8h” as the salt; it will spit back “8h48GPxmwy.EA”.
Update 3: “OFFER HN”: The most paltry “Offer HN” ever — send me your username or email address and I’ll grep both files for you to see if your password and/or hash is in one of them. My email is contact-at-<HN username>ogan.com
One liner to find if any of your Facebook friends had their password compromised:
grep -o '[[:alnum:]+\.\_\-]*@[[:alnum:]+\.\_\-]*' yahoo_ab.csv | while read line; do grep " $line" parsed_db.txt; done
For those not in the know, you can export a CSV of your Facebook friends' email addresses in under 4 minutes by following this guide: http://lifehacker.com/5690378/how-to-export-your-friends-ema...
which yields a yahoo_ab.csv. From there you can cross check it against the parsed_db.txt file or the full_db.log
You should probably tell your friends if they're showing up in the parsed_db.txt as one of their passwords can now be seen by anyone.
I already did this. I'm tempted to set up a utility page where you enter your email and the utility just tells you if it was in the DB, but I don't know how legal that would be. Checking the data for personal defensive purposes is arguably defensible - setting up a tool based on that data (even benign) is likely less so.
For people who can't remember if they ever signed up:
Go to gawker.com and use the 'forgot my password' utility. It's under login > forgot my password. Enter your email address in the field provided. It will tell you straight away "That email address is not in our records. Please try again."
I can't think of any reason this would be incorrect based on the recent events. Of course, this doesn't tell you whether your password is vulnerable, just whether you have an account.
Apparently somebody thinks they're a "white knight" I just got an email from "The Team at Hint" (teamhint at hint dot io). The text is:
Hi there,
Hint wanted to let you know that your email address and password that you used to signup for Gawker (or one of its sites) were hacked. Forbes' coverage is here
In situations like this, time is of the essence, which is why we were surprised & shocked to find that Gawker Media hadn't taken the initiative to notify you of this privacy breach immediately. We HIGHLY recommend you change all of your online passwords as a precaution.
I can't see how it's unethical, unless even looking at the data is unethical, and you'll have to convince me of that. I'd be more concerned about the ramifications than the ethics. The least bad thing that could happen here is winding up on some big ISP's blacklist because enough of their users marked this unsolicited mail as spam. Once that happens, good luck communicating with your customers.
I'm sure you can imagine the worst that could happen. Courtrooms are not happy fun places.
"Unsolicited scary email from some guy that got my email from a hacker" sounds like it would only be slightly less legally dangerous than just straight up forcing hashes and posting them.
Definitely better than always reusing. But it’s still semi-vulnerable if for some reason your plaintext password is discovered. gawk--yourpass does kind of suggest bank--yourpass.
Go to gawker.com > "login" > "forgot password". Put your email. If it says it sent a new password, then they had it. "Username was not in our records" -> it wasn't.
If the servers are still compromised, I don't think they'd have stopped with a dump full of hashes and a few posts on Gawker. My guess is that the intrusion was discovered while they were doing the dump, which is why it's incomplete.
thanks for posting this - it works great. just to summarize- here's what you want to check if you're password has been compromised:
1) fire up terminal on your local macbook and enter the above string subbing in your password
2) open the spreadsheet and set the filters to domain - enter your domain name(s) and hit submit
3) If any results are returned then compare the MD5 hash in the result set with the MD5 hash returned from step #. if they're the same, start changing your passwords.
Can anyone lookup my name? I'm not in access to my personal email to send an email to the OP. I don't remember I have used comments of Gawker sites but anyway to be sure. The user id i generally use is same as here. Thanks.
I manage a domain through Google Apps, and I've discovered that that domain is on the list.
It's probably me, but I can't figure out what address was used (none of the md5 hashes are matching that are in the fusion table).
Seeing as you've got this for analysis, it'd be nice if you could help me figure out if one of my users was compromised (the domain is the same as the email on my hn profile).
It'd really suck if I have to change my password scheme because of this. :|
It's the one starting with 7335e7777f449de7533bfcc81efda
For the past 2 years I have been ashing all my password with custom algorithms in a hashing bookmarklet but I don't even remember when or why I created an account on there and I am curious on which password I've used.
This is serious. I just checked out the torrent with the text file of the 200,000 cracked passwords. I searched for @me.com account and logged into someone's apple account. It was possible for me to order stuff via their account. I quickly emailed the guy to let him know to change his password. Gawker needs to take responsibility of this situation and email everyone in their database.
Gawker posted password change guidance on its website, but no mention is made of having attempted to directly contact those affected, so I'll assume they didn't. I don't know who's handling this for them.
We have the list. Anyone with a MailChimp account want to be a good samaritan?
Edit: I'll certainly help, but I and my girlfriend, Stella Artois, have been lamenting the embarrassing loss our Jets suffered this evening, so I figured I'd float the idea for vetting first :)
Edit 2: Wow: I know a lot of people on this list. I'm letting them know, and recommend that others scan on behalf of friends and family as well. I've been told that there has not been active communication; wish gawker would confirm either way.
This is what happened with monster.com and a lot of other big sites that got hacked. I bet most don't even make it public, much less email their members. They work so hard on brand reputation and image, then it all goes down the drain because some admin used a weak pass. It's not so easy for them to throw away their christmas bonus and job security. They'll do the minimal.
I wasn't notified either. At least not by Gawker. Apparently the people at hint.io took the initiative to send out emails, which is nice of them, but hopefully they don't use the email addresses for anything else.
Looks like it is quite easy to shut off ads on Gawker. They do a simple boolean check to see if you have a "noad" cookie set. Try entering this into the console.
javascript:document.cookie='noad=true; expires=Thu, 2 Aug 2021 20:47:11 UTC; path=/';
This shuts everything off, except for one ad at the top.
(Put a bookmarklet for this if anyone who wants to try it out: http://bit.ly/exvive)
Has anyone checked if source/ contains the source for their proprietary CMS?
From Felix Salmon:
Most of the value of Gawker Media lies in Hungary—but how much value is there, really? To a large degree that depends on what Denton decides to do with his proprietary technology. Other blogging platforms are worth nine-figure sums—Tumblr just got a valuation of $135 million, while Automattic, the parent of WordPress, turned down a $200 million acquisition offer three years ago, when it was much smaller than it is today, and subsequently raised money at a valuation north of $150 million. I know a lot of people at big media companies who struggle with the limitations of WordPress, and who would pay good money to license an alternative web publishing technology, if it was robust and proven. Big companies are already licensing the NYT’s Press Engine mobile-publishing technology, and it’s rumored that at one point Denton was talking to Bonnie Fuller about licensing his technology to her nascent website, although that never happened.
The archive of trunk appears to be one with shared assets, not the development trunk of the CMS. I could be wrong however, but I see no similarities between the layout of "trunk" and the other archives that were clearly live web-facing assets.
Worse, the Gawker post on the issue http://gawker.com/5712615/commenting-accounts-compromised-++... releases no details. Instead of giving a detailed description of what happened, they simply say, "change your password." With that level of detail, you might think they're now afraid to even write "4Chan."
I've download the torrent, convenient of them to give an email address with each cracked account.
I'm currently writing a little script that parses all the address and emails the owner a heads up. I gotta step out so I won't have it done for 2-3 hours and I thought I'd post here in case anyone else has that idea (don't want to flood the victims).
Sounds like they probably used social engineering to get initial password(s) and thanks to poor security practices used those to go from there? Not to sound malicious or impersonal, but breaking something so wide open is like a solving a hard puzzle, I'd be really interested to hear more details on how they actually did it.
I can't stand Gawker and Gizmodo and the shit attitudes of the people there. Love to see their attitude in Basecamp and see them get owned hard. I know it's juvenile, but I'm just being honest. Now I'm going to go check and make sure I didn't have an account with them, ever.
Random datapoint: My e-mail was one that got hit in this hack. 15 minutes ago my Twitter and Gmail both just locked me out. I was able to set new passwords via mobile verification, but that was pretty spooky and clearly someone is going after the people who got exposed here.
Even if you're not, my email address is getting spammed with password reset attempts for Battle.net, LinkedIn, Facebook, Amazon, one of my banks, Twitter, etc.
Granted, all had different passwords, but people are taking full advantage of this information being made public.
Personally I'm not as worried about Gnosis or 4channers doing anything particularly malicious with the data -- that's not their goal. Their goal is to publish it so other people do malicious things with the data, with all the resulting animosity being directed to Gawker.
Having seen the pastebin link, these guys use really, really poor password. Only alphanumeric - usually just one of the two - rarely with capitalization, and nothing else.
The parent comment is likely referring to admin & username passwords for people working at Gawker Media, such as Gizmodo, Lifehacker, and Kotaku contributors.
All the usernames and passwords for users with {@lifehacker.com, @gawker.com, etc.} email addresses in the torrent (plaintext, not hashed). The torrent claims Nick Denton’s password was an 8-character sequence of even numbers, and that he used it everywhere. (Edit in reply: The hackers used this on e.g. his Twitter account IIRC so it wasn’t truncated to 8 characters.) Some of them are even '11223344' or a substring of the author’s username!
This isn't entirely accurate. Their hashing mechanism only hashes and stores the first 8 characters of the password. So you only need to get the first 8 right, even if the password is 12 long.
That also means that, although unlikely for some, '11223344' could have actually been '11223344aBc$!q'. Not that it would have mattered though!
It matters a little outside of Gawker, right? Because a site that requires all of say, 12 characters, if the remaining 4 weren't predictable, would be safe even with the first 8 exposed.
Yeah, but only as “safe” as a 4-letter password. Assuming full alphanumerics, that’s only 14 million possible 12-character passwords to try. Given a 1GHz processor, well, you see where I’m going with this.
This is why I freaked out when bluehost.com (AVOID!) required the last four characters of my password to accompany support requests(!).
Yeah I was just using the 12 as an example, but someone with say 36 chars past the 8 recovered from gawker should be a little more at ease.
I don't think I've logged into any of their sites, I use different passwords at different sites and they are generally > 20 chars, so I'm not worried. Yet, at the same time, even knowing all of that, I did a bit of a double take and had a brief "Oh shi-" moment of paranoia when I read the headline.
In fact, if I were say a young starlet that used a similar password for my private email or something as my Gawker account, I'd be really freaked!
Realistically, this isn't likely to compromise a strong 12 character password without a second breach at a different site. (In order for your 1GHz processor to have any bearing on the discussion, they need not only Gawker's password hashes, but another site you coincidentally have an account at that uses the same password.)
I was under the impression that the ones that were displayed w/ password were just the ones where the password was reversed from the hash. Does that apply to all accounts, or just to ones with weak passwords (i.e. there may be selection bias in that list).
It lists a bunch of the password/email combinations (plaintext), and tells a bit about how they did it. I'm guessing they used a dictionary attack for the easy ones. Also displays chat logs from campfire that show the staff in a highly unfavourable light. Then again, their work does that just fine without any outside help.
California's SB 1386 does not seem to apply, as there is no "Personal Information" in the leaked database.
One thing open to interpretation would be whether the password in the file could be used to access someone's bank account. If someone uses the same e-mail address and password at both sites, that would be true.
Section 1798.29, E, 3
-- Definition of Personal Information
Account number, credit or debit card number,
in combination with any required security code,
access code, or password that would permit
access to an individual's financial account.
Does anyone have any information on changing all their account passwords at once? I don't use the same password for any sites, but unimportant sites like blogs, etc. I use fairly similar passwords on.
As for all files that have recently been removed from thepiratebay, they are still reachable with this url (where ID obviously is the numeric ID seen in the original torrent URL):
OpenID as a solution, not so much. It's a roundabout solution to a bigger problem. A solid password distribution and management strategy is far more effective. 1Password for Mac handles that pretty well for me.
The biggest threat would be a new version of the software with some malicious aspects. They'd have to upload it and remain undetected long enough for people to update. This seems like a long shot, but stranger things have happened.
I use 1Password, and it sure beats my old strategy of using a text file for all my unimportant passwords.
Coincidentally, the 1Password plugin is helpful in preventing phishing, too. If you're at the wrong site, the 1Password autofill will not work.
After all, if 1 password gets hacked the passwords that are generated could be sent to two parties instead of just to you.
And if someone mounts a camera in the smoke detector in my apartment they could see me type in the double super secret password whose plaintext has never been stored by a computer.
So what's your point, exactly? Tools which generate good passwords and store them locally on your computer with decent-enough security are light-years ahead of what most people do, and their use should be encouraged.
They're not open source, and I don't see any checksums on their site - so it's possible that their site could be hacked and have a trojan version uploaded. Harder to do for the iPhone/iPad version, but it might still be possible for a clever hacker^Wcracker to put something into the source code if they can get access to it.
Yes, and a clever hacker might sabotage my C compiler to always build a back door into software it compiles. Even if the compiler's open source that can be hard or impossible to detect.
But in my experience, too many people confuse "this is a possible threat" with "this is a threat it's reasonable for me worry/take action about", and that's what I was getting at.
C compilers are distributed with checksums and public key signatures, plus it's possible to decompile generated binaries and examine them - so it's at least an order of magnitude harder to compromise them.
1password is easier and a much juicier target, so compromised binaries are definitely a possible threat. How would you know it was compromised, unless you had a packet sniffer going on your network?
Again: you're saying "possible threat". I agree it's possible. What you have not demonstrated is that it's likely or reasonable enough to serve as a basis for changing my own actions.
It's possible that a password manager could be completely open source, distributed with checksums and public key signatures, that my C compiler could be completely open source and distributed with checksums and public key signatures, and I could still end up with a backdoor in the final compiled result, detectable only by deciding to carefully examine the binary I just built.
This is a "possible threat". Should I use that possibility as a justification for never using a password manager? Or for never using a C compiler?
Simply put, you need to have some assurance that the binary that you're downloading is the one that the developers compiled, and the easiest way to do that is to have crypto checksums. If you don't, all bets are off.
And it's not just a "possible threat" but a likely one, and it's happened multiple times in the past. Sites get hacked all the time, and trojans are standard practice these days (unlike compromised-binary-generating C compilers):
Yes. There have been attempts in the past to insert critical vulnerabilities into open source libraries that would make programs compiled against them vulnerable.
What your suggesting is far less complex than the Stuxnet virus. You need to get binaries from reliable source and verify checksums whenever possible. You can't protect yourself a 100%, but that doesn't mean you should leave or your doors unlocked.
Gawker uses a really outdated hashing algorithm known as DES (Data Encryption Standard). Because DES has a maximum of 8 chars using a password like "abcdefgh1234" only the first 8 characters "abcdefgh" are encrypted and stored in the database. If your password is longer than 8 characters you only need to enter the first 8 characters to log in!
Is this true? I tested it now and it needed the full password for a successful login.
I'm not a cryptographer by any means, so please forgive and correct any errors. I'm assuming you're just saying that building rainbow tables once you have a static salt and the hashes becomes a feasible proposition? Wouldn't using a dynamic salt with each hash make a full dump like this significantly less crackable than DES with several weaknesses and a 56-bit cipher? (And that's, of course, assuming that the DES key doesn't leak along with the dump.)
DES crypt(3) doesn't have a "key"; it truncates/pads passwords into a DES key used to encrypt (with a salt) an all-zeroes block. It's horrible cryptography, but it's slower than SHA1.
How so? People have found collision attacks on SHA1 that are significantly better than brute force, but I thought it was still safe against finding a plaintext that hashes to a given hash value.
I've been trying to find this out also. There's no indication that they are; but the only indication that they aren't was them saying that shorter passwords will be much less secure.
Ignore this and see tptacek's post about bcrypt instead.
This is why my preferred hashing scheme is username + seed + password, so that even if user1 and user2 both use "password" as their password, they'll end up with different hashes. That way if the database is compromised you can't do frequency analysis against the hashes to make guessing common passwords easier.
Regarding bcrypt - does it still make sense to do seeding on those since the key wouldn't be changing? I've also seen wrapping sha1/etc and looping it like 1000+ times to introduce a time factor in, but that doesn't seem like the best solution.
Suppose I'm not able to use bcrypt for legacy reasons. Would a hash of username+password+constant_seed be good enough? What about user_dependent_seed+password+constant_seed? The user_dependent_seed could be a concat of username, account setup date, user id# etc. What hashing algo would you recommend if bcrypt is just not available?
The attraction of bcrypt is that you can tune its work factor to counter increases in computing technology, so that it's very slow to brute-force compared to an MD5/SHA/CRC, all of which are extremely fast to compute. It's counterintuitive, but the idea is that if Joe Blackhat gets your password hash, he's going to spend orders of magnitude more time chewing on it to get a result than if it were hashed with a fast hashing algorithm. Adding more salt to the hash is going to increase its time-to-crack, but swapping SHA1 for bcrypt gets you a future-hardened algorithm that can be adjusted in responses to gains in computing power.
I agree why bcrypt is much, much better. No doubt about that. My question was whether there was something I could do to improve security (even if marginally) on platforms that can't/don't support bcrypt.
> bcrypt gets you a future-hardened algorithm that can be adjusted in responses to gains in computing power.
How would I be able to change the cost factor overtime? I don't store my user's passwords. Should I just re-bcrypt the bcrypted password using a higher cost and in my login_verify code, take that into account? Or is there something else you can do overtime to raise the cost factor?
"How would I be able to change the cost factor overtime?"
One system I built stores the workfactor used to bcrypt the current password un the user table, and allows me to increase the "system workfactor". Every time someone successfully logs in with a lower-than-current-workfactor password hash, it recomputes a new bcrypted hash using the currently known successful login password and updates the users credentials. It means if my user table is ever exposed, all frequently used accounts have up-to-date workfactors for their password hashes, and the "relatively weaker" hashes are for infrequently used (or, in this particualar case, expired subscriptions).
Iterate MD5 several times (i.e. 50 or so). That will introduce a similar "slow" factor (it's not a solution, but a stop gap)
EDIT: I've also recommended using a random salt for each password too, but this is only a layer of security if you're code is not also stolen, then it is simply a slight additional "slow factor"
If anyone has a comment as to why this is not good advice (it honestly is decent advice if you really insist on not using Bcrypt) then I'd be happy to hear it ;)
Because md5 is stupidly fast, even if you use a thousand cycles. As if that's not bad enough, there are FPGA implementations (http://nsa.unaligned.org/) which are even faster and relatively easy to come by.
Yes, MD5 was a mistake :) I was tweaking our cluster's MD5 implementation so it was stuck in my mind. Just sub in "hash function".
You could up the iteration however much is needed (say, 1000, 10,000).
It's poor security countermeasure, but it was a specific scenario :) The general idea is to combine salting and iteration to produce a poor mans slow hash.
(which works great for software you're distributing for use on random shared architecture a la wordpress - just to give an example)
That's the crux of the problem. Hashes that are good for fingerprinting files (MD5, SHA-n) aren't good for keeping passwords secure, because they need to be fast. Your idea seems fine, but you're forgetting the "first rule of implementing crypto primitives": don't do it! (http://www.letsyouandhimfight.com/2010/07/14/cl-bcrypt-a-fir...)
Nonsense. I am well aware of the problem with hash functions.
First off; it is not a primitive, but a protocol, it is still a bad idea to design those yourself. But they are not; they are getting the advice of an expert.
Secondly; this is in a specific scenario where you are left only with the fast digests (shockingly, this is still a common situation). Introducing an "artificial" slow factor is accepted practice.
Thirdly; this is definitely not my idea. The iteration suggestion was from tptacek who months ago answered a similar question to this with something along the lines of "if you must insist on using fast hashing for gods sake iterate it a number of times" (I can't find the quote off hand, it was some time ago, but I entirely agree). The rotating random salt is an old old idea.
It's very easy to recite the mantra "always use bcrypt, follow the first rule of crypto, digests are evil", but it's even harder to use that knowledge in practice, I find. :)
You can introduce slowing factors like seed values and iterations (bcrypt uses both) but they're a bad idea if you're doing it yourself. For example, your initial estimate of 50 iterations is at least a couple of orders of magnitude out. How many is safe? 10,000? 100,000?
BTW, I'd be interested to know exactly what this mythical situation is where you're handling user accounts, but don't have access to one of the existing bycrypt implementations (C, Ruby, Python, PHP) and can't compile your own.
It's not really a primitive, but I'll concede the point. Similarly the one about 50 iterations, that was somewhat silly (there is a reason I have that number in mind, but I won't bore with details).
However. Mythical situation? Try a good portion of shared PHP hosting; why do you think the most popular software in the world (i.e. stuff like Wordpress) still supports MD5/Sha hashing?
I realise this is not a problem you may have come across before; but don't imagine it does not exist :)
So use PHP-ass: http://www.openwall.com/phpass/. It's integrated into Wordpress and does all of that stuff, including falling back to md5 if you have a really crappy host.
But really - it's just another reason not to use PHP, and not to have a crappy webhost. You could probably say much the same things about backups, app security, bad UI or design. But for most people, don't do that is apparently not a good enough answer.
Update: Just looking into how Django stores passwords, and it does much the same thing (although it falls back to SHA-1, rather than MD5). There was a push to use bcrypt a while back, but it got marked wontfix, due to "backwards compatibility issues". Sigh.
Since the username is unique, I tend to use a sitewide seed. My understanding of the seed is to make rainbow tables useless, so adding any unique data should help with that. Granted, now that you can fire up a GPU instance on EC2 and generate SHA1's like a madman, bcrypt does seem to be the way to go, but at least (as far as I can tell, would love to hear if my reasoning is incorrect) by including the username + password, you'd need to generate those rainbow tables against each user.
That's correct, but as you pointed out, with massively parallel cloud computing available for so cheap, you really want a slow function to shove that data through.
I wonder if there's an option for an ISP to proactively secure these accounts. GMail has phone verification for backup, they could temporarily disable the account of anyone who has a matching password.
Odd, I'm sure I had a lifehacker comments account, but my username isn't listed. No complaints though.
I have an io9 account (that's a Gawker site) but my email isn't showing up in a grep of the db dumps. Perhaps this is not the entire database after all? (I didn't use Facebook Connect.)
I must admit I'm a bit intrigued as to why mine's not there. Anyone else in this boat?
After gaining access to gawkers MySQL database we stumble upon a huge
table containing ~1,500,000 users. After a few days of dumping we
decided that 1.3 million was enough.
I'm in there, and I'm grateful to the HN community for showing me how to find out. This is rather alarming...I've passed it on to my newsletter subscribers, Twitter, Facebook, etc.
Kind of ironic really, considering the whole secrecy vs non-secrecy debate.
I'm currently sending emails to the first 50,000 addresses listed in the database dump via SendGrid. I only have 50,000 credits left for this month, but at least that many will get notified.
A bit too late now, but that violates at least the first three terms of the SendGrid e-mail TOS and I wouldn't be surprised if SendGrid got a "bit upset" about it..
Well, haven't actually clicked the send button yet.. was waiting for the import to finish. I'm second-guessing the foolhardy good samaritan effort now, though. ;)
It's a free account that I got via an AppSumo bundle, so no real loss to me if it gets terminated, but I'd rather not go that route to begin with, ya know?
This is what mailinator and, failing that, tenminutemail accounts are for. Why people sign up for random sites with their personal emails just to comment on articles is beyond me.
The passwords aren't very important, although I can see why that'd be an issue. But those internal chat logs are going to be a bit of a problem. For Nick Denton, that is.
If I had to bet? Firesheep or similar + a writer sitting at a Starbucks. Your guess is as good as mine, though. Campfire's under SSL, but people re-use passwords and it's trivial to lift a password-in-the-clear off of a public wireless hotspot. If you wanted to target Gawker, it wouldn't be hard to identify people practicing poor security and just watch them until they slipped up.
Weird... One of my throwaway accounts appears with a name I know I've never used before. Then again, I had someone sign up for a Facebook account with that email address once too...
WTH? Why downvote this? Especially as I've seen users on Gawker's sites, HN and reddit mention the same issue. Really? What is the purpose of downvoting this?
Remember, don’t use the same password across the Internet. Here’s why.
Edit: It’s there, apparently as a DES hash. …
Update 2: The first two characters are the hash. So if you use a tool like https://hash.online-convert.com/des-generator you are going to put your password in the “Text you want to convert…” box and the first two characters of your hashed password in as the “Salt (optional)”. Then you will see the “Calculated DES Hash” which will be the same as the hashed password from the torrent if you knew or guessed the password correctly.
E.g.
Your Lifehacker password is “hackern”, but in the torrent, it’s just “8h48GPxmwy.EA”. Just to show the torrent is legit, you go to the website I entered above, enter “hackern” and “8h” as the salt; it will spit back “8h48GPxmwy.EA”.
Update 3: “OFFER HN”: The most paltry “Offer HN” ever — send me your username or email address and I’ll grep both files for you to see if your password and/or hash is in one of them. My email is contact-at-<HN username>ogan.com