Tell HN: Hacker News Profile Leak (Fixed) | Hacker News

Affected profiles were leaked on one of 10/12, 10/20, or 11/02. In every case, the leaked data was overwritten 30 seconds later by the subsequent update batch. The leaked password hashes were salted bcrypt (FreeBSD's default libcrypt implementation). Though we think the risk is low we encouraged affected users to change their password on HN as well as on any other sites where they used the same password.
Many thanks to Ovidiu Toader for alerting us to the bug and for sending us examples that assisted us in tracking it down. While the bug was fixed on Sunday, November 9th within minutes of our becoming aware of it, Ovidiu originally reported the issue one week prior - we just didn't see it in a timely manner.
To help improve our future response times, we've created a dedicated reporting address, security@ycombinator.com that we'll publish on our contact form. We're also creating a "Wall of Fame" to properly thank and credit past and future vulnerability reporters. More details will follow.
Super sorry about this,
The Hacker News Team
A clarification, since some people seem to be misunderstanding: Only publicly available data is intentionally pushed to Firebase. That any part of a user's profile other than their username, account age, about text, and list of submitted items was published IS THE BUG, and is now fixed.
This has me curious. Why 100? Why not 0 or all? 100 seems to indicate you're aggregating the 100 most recent votes for some specific purpose, and that the feature unintentionally leaked the data.
I wonder if mods have the ability to go to a page, type in a username, and see the 100 most recent things they've upvoted/downvoted? I guess as a way of looking for voting rings?
I often upvote comments I feel are unfairly downvoted, definitely not because I agree with the comment. Hopefully vote history isn't being used as a metric of character. Then again, maybe it's a useful filter. I've often wished Reddit would drag down comments from people who upvote angry bully-type comments from other people, so there might be all kinds of interesting ways "100 most recent votes" could be used.
I demand that youtube video now. Amazing skills abound!
[0] Mirrored at https://github.com/wting/hackernews
Either that, or a program is aggregating the 100 most recent votes in order to be used in some filtering or weighting algorithm to change the ranking of comments. (People who upvote what YC alums/patio11/tptacek/etc upvote may be upvoting high-quality things, so make their votes count more. That sort of thing.)
I guess it might improve server performance if the server caches your 100 most recent upvotes for page generation purposes, since when it serves you a page, it has to know whether you've upvoted each comment or not. But it seems like a stretch to say it's only used for that purpose, because it still needs to know whether you've upvoted things from very old pages, yet the list stays at exactly 100 items. And they already hunt for and punish voting rings. I was just wondering the extent to which votes are scrutinized.
EDIT: The more I think about this, the dumber I sound. The dataset that was leaked was almost certainly used to generate pages and nothing more. It's the simplest explanation, for one. Manually looking doesn't scale. The program to look for voting rings is probably a completely different program. Etc.
[0] It appears this is not the case with the vote caching from staff comments in this thread.
As bad as data leaks are, it's at least nice to see one of these data leak stories where the passwords were actually stored correctly, instead of being MD5 / plaintext / base64.
The reason we see so few hacks where passwords were stored properly might be because they do things properly, so odds are lower they get hacked in the first place. Just a thought.
Also bcrypt does not seem to be FreeBSD's default libcrypt implementation from the source code [1] - it appears to be DES (or SHA512 if DES isn't available). What makes HN think it's bcrypt? @kogir?
[1] https://github.com/freebsd/freebsd/blob/master/lib/libcrypt/...
The docs are here: https://www.freebsd.org/cgi/man.cgi?query=crypt&apropos=0&se...
The code looks something like this:
I'll up the number of rounds and upgrade them in place as users log in. Thanks!
Even if that weren't true --- and it very much is --- you'd still trivially be able to find that number given a single known password.
I understand that it's because the salt is entirely appended in clear to the hash. Isn't it better to have a second static salt implemented in the code, in case only the database would be compromised?
Now there may be other bcrypt attacks out there, but none have been announced, and the usage of bcrypt was announced in the text of the post.
Furthermore, if you have the hash, you have the number of rounds. I just have no desire to see if I can download the data (I don't trust random sites, and frankly I don't want the data).
Security by obscurity is not worth the price you pay for it.
That's why I was posting this. Many people think that because of the Kerckhoff principle you should always disclose everything. But obscurity is not always a bad thing and it can be part of the obfuscation here. Although here it was indeed a good thing since admins are gonna up the cost of their kdf following advice from the community.
• Quickly • Transparently • With a fix already in place
It's never fun to be on the receiving end of these e-mails, but the HN leak e-mail was the most responsible data-leak notification I've received.
Thanks for being professional and responsible!
This was a case of rare error handling having unintended side effects. The profiles were only published in one very unlikely case.
Can you comment on what this case was? I'm just curious.
Yes, for two different meanings of "error". I wonder if this ambiguity is part of what was confusing, so let me disambiguate.
There was a programming error in some error-handling code. If that makes sense, yo