That is extremely lucky. That's, what, 82 bits if you'd chosen the whole thing?
A more manageable 61 bits for 12 characters or so, from my recollection. Did you pile a dictionary attack on top of that?
I don't believe this does "break hidden services". That's just a truncated key fingerprint, not the key, and a collision would I suspect (but haven't checked) be a loudly visible error.
>That's just a truncated key fingerprint, not the key, and a collision would I suspect (but haven't checked) be a loudly visible error.
Actually, a name collision would still mean hijacking the traffic, even if they don't have the same private key. The last HS to announce "owns" the name.
You got so lucky that you'll probably want to keep using that name forever. The longer it's used, the greater the probability of compromise of its secret key.
Which is why using TLS on top of the .onion address is brilliant: even if the secret key for the .onion address is compromised, the TLS certificate (which is rotated more often) will keep the connection safe. The worst that could happen would be someone hijacking the .onion address, but that would lead only to a DoS instead of the compromise that would happen without the redundant TLS layer.
And the certificate also helps validate that the .onion address is really from facebook: as someone observed elsewhere in this discussion, the certificate is also valid for the non-.onion addresses, so just examining its alternate names extension is enough to prove that the certificate owner could also get a valid certificate for www.facebook.com (meaning the certificate owner is very probably facebook itself).
Someone else said getting SSL certs for .onion in the SNI doesn't require ANY kind of validation.
So someone bruteforcing the .onion key could easily get their own valid SSL cert and have full access to the plaintext for anyone browsing the .onion site over SSL.
The security of facebook over onion is now only protected by the hash power required to brute force the vanity address, instead of the integrity of the SSL CA system or the power required in factoring an SSL key. Even the requirement to spoof DNS or perform actual man-in-the-middle-of-the-wire hijacks has vanished.
This is a good idea for other tor services too as that 1024 bit RSA is looking pretty shaky these days. Hopefully the tor devs will give it a bump to 2048 or move to Curve/Ed25519 soon, before this becomes a real problem.
I'm a software engineer at Facebook working on security and privacy. This is simply a hoax. The html source shown in the video clearly says "No test user was deleted". We've verified in our logs that the victim account was manually deactivated by visiting https://www.facebook.com/deactivate.php. Anyone can visit https://www.facebook.com/whitehat/accounts/ and verify that the query parameter used by this endpoint is selected_test_users not selected_users. We've also audited our code to verify that there's no variant of this exploit that works against that endpoint or any other that we've found. In fact, the most recent code change to this endpoint was in April and was routine maintenance that had no security implications.
Re: #2. Basically correct. Reporting a range that includes all requests, including those that can't be disclosed individually, is the best outcome we've been able to negotiate so far. Here's the answer in the FAQ:
Why did you report the numbers for the United States in ranges?
We have reported the numbers for all criminal and national security requests to the maximum extent permitted by law. We continue to push the United States government to allow more transparency regarding these requests, including specific numbers and types of national security-related requests. We will publish updated information for the United States as soon as we obtain legal authorization to do so.
No. If users send unencrypted data to a service provider, they can never use technical means to verify what the service provider does with the data. For example, suppose that some category of user data is automatically printed out on paper every night.
I'm a software engineer at Facebook. Requiring login for this page was a simple oversight and should be fixed sometime this evening California time. Sorry for the confusion.
I work on this at Facebook and we do permanently delete your content when you delete your account. It's an interesting distributed systems problem, and we're happy with the framework we've developed for this. We're working on a blog post with more details and hope to publish that soon.
Just to vouch, though not in Facebook's case, it is complicated.
Many sites use a CDN (Akamai, Limelight, Amazon's Cloudfront, etc.). The whole idea of a CDN is that it distributes content. Even if the origin goes away (your copy), the CDN may continue serving it for a long time. If someone has a specific item URL within that network, they can still access it. Working with CDN APIs to delete content (especially if, say, that content has various instances based on sizes, previews, etc.,) can be ... interesting.
And if third parties are presenting your content, they might also persist it, say as a Google preview or cache, or Archive.org, or other tools.
Even within your own systems, data can be replicated in ways which are difficult to access fully. Backups can exist which cannot be easily accessed for wiping. There are war stories of magically re-appearing data resulting from data recovery operations.
So, while it's possible to flag content as "don't present" pretty easily, actually rooting all of it out thoroughly can be a much more involved task.
My name is Scott Renfro, and I’m a software engineer at Facebook working on security and privacy. I thought I'd post the comment I submitted on the original blog post here as well. We’ve put a lot of work into making deletions permanent, so I can imagine how frustrated you must be. I’m pretty sure those story deletions are permanent, and I can’t think of any place where we can or do automatically restore user-deleted content months later.
If you happen to have any more details about specific stories that reappeared, I’d love to try and figure out exactly what happened. Admittedly, that may be difficult now that several months have passed.
As one of the other commenters mentioned, your Activity Log is a better place to get a full list of your activity and delete it item-by-item. It also shows posts that Timeline omits and includes other types of content such as likes and comments. This help page may be useful https://www.facebook.com/help/activitylog and you can find your Activity Log at https://www.facebook.com/me/allactivity?privacy_source=activ...
I couldn’t tell from your description, but one possibility is that you only saw and deleted the stories rendered on your Timeline, which is just a summary of your activity.
As long as you're here, any comment on the (current) top-rated comment by lukejduncan? How can we trust that our private information today won't be similarly exposed by a settings change tomorrow? (I hope that nothing I've posted would endanger my relationship with my family, but I know others aren't as safe.)
I'd like to think we wouldn't need to make such a fundamental change again in the future, but if we did decide it was necessary, I hope that we would give everyone plenty of time to make whatever change to their account was necessary to avoid painful outcomes like that.
Random engineers, even awesome ones like Renfro, don't have anything useful to say about what the SVP of Product is going to decide about how facebook.com will behave.
>We’ve put a lot of work into making deletions permanent, so I can imagine how frustrated you must be
It shouldn't be necessary to put a lot of work. Just delete the content, clobber it with blank fields, or randomized content. It really is very easy.
The problem is that your company's policy is to never truly delete content despite calling it "delete", there are many ways to weasel-word it ("many software subsystems don't truly delete" blah blah) but when someone asks a third party to delete something (s)he doesn't ask for it to have it marked deleted. Just delete it.
Surely not your fault though.
PS: there's no money in this world so that I'd work for a company with the morals and values of Facebook.
When the delete button affects a single row in a single database table, it's indeed really simple. Even if it's a few rows on a single database, you can use transactions. Either way, the deletion succeeds or you surface an error message.
But for a large social site, it starts to become a more interesting distributed systems problem.
Even for a simple story with 4 likes, 12 comments, and likes on several of the comments, the data is sharded across several databases. Simple transactions no longer work. One option is looking for scalable distributed transactions. A more likely option is making sure deletions can be interrupted and restarted without losing state.
Now imagine a public figure whose post has tens of thousands of comments and hundreds of thousands likes. You may not be able to load all of those rows in a single request let alone delete them synchronously. Instead, you have to be able to process the deletion incrementally, reading and deleting some of the data then later picking up where you left off the last time you were interrupted.
Interestingly, the order of these operations can also be important. If you're interrupted between deleting a comment and deleting the likes on that comment, will you still be able to find the likes when you restart?
We've put a lot of work into a deletion framework that deals with these and many other issues. We're hoping to share more details about it in the future.
Well comment tree deletion is a harder operation than post creation or comment creation or liking.
Each of the steps in building up the tree of comments, likes, etc. is a a couple writes at most. If that fails, you're left in a safe state. You tell the user it failed and carry on.
Deleting a post and the comments on it is harder. First, you have a potentially unbounded amount of DB rows to delete across an unknown number of shards. Second, you now have to worry about the order in which you delete things, else you risk being unable to retry in case one of these deletes fails. Third, unlike the inserts and updates, you can't just give up partway, as that's not a safe state to end in.
