Sign up ×
Information Security Stack Exchange is a question and answer site for information security professionals. It's 100% free, no registration required.

Is it safe to transfer Facebook access token via TCP? What is the worst that can happen if someone gets the token?

share|improve this question

migrated from Dec 13 '11 at 22:41

This question came from our site for professional and enthusiast programmers.

2 Answers 2

Depends on what you're trying to do and what kind of TCP connection you're using.

To keep it short, I'll give you some things to consider:

  1. TCP is just another transfer protocol like HTTP. If it's unencrypted, stuff like eavesdropping and worse might happen. But since you're not launching the next version of WikiLeaks, you might just be safe when you transfer that access token unencrypted. Yet, I'm not saying I recommend it!
  2. The Facebook access token itself is pretty safe to transfer if there's no connection to other data. Meaning: no one would know what a random string of characters would be for if you don't transfer data that shows more information next to the access token itself.
  3. The access token is only part of a whole. Just having it won't kill anyone's Facebook account.

As said: TCP is just like FTP, HTTP and all the other protocols. If it's not encrypted, people can fetch and put to use intercepted info more quickly. As a quick answer to your generalized question, this should satisfy.

If you expect an in-deep risk analysis, we (the people trying to help by answering) would need to know a bit more about the "Why TCP and what for". But in the end, you'll end up with an encrypted connection (TCP or other) if you want to be 100% sure that you're SAFELY transmitting Facebook access tokens somewhere else but Facebook. Think of it like your MySQL database... you're not storing passwords unencrypted either, or are you? Same goes for transmitting sensitive data: keep it safe and encrypt what you can because you never know where the next script-kid might be lurking to ruin your day.


Why do I get the feeling the shortest answer would have been a simple, two-letter "no"?



As some comments show that there is a big lack in understanding data security, I'll add a few lines.

Some argued HTTPS does in-stream encryption. It doesn't. HTTPS combines Hypertext Transfer Protocol (HTTP) with SSL/TLS protocol.

HTTPS transmissions might be encrypted, but from a SECURITY point of view, everything can be intercepted - encrypted or not.

Next, some seem to mix up HTTPS with the less used S-HTTP (Secure HTTP). There is a big difference!

look at the question

The question was:

"Is it safe to transfer Facebook access token via TCP? What is the worst that can happen if someone gets the token?"

The answer is NO, you need to use secure protocols to avoid eavesdropping/man-in-the-middle attacks.

But let's assume the OP is smart and uses HTTPS as an crypto wrapper. With HTTPS you might avoid eavesdropping/man-in-the-middle attachs, but you can't ignore that a Chosen-ciphertext attack will still be successful! For a first read about this, check "LIMITATIONS of HTTPS" at and "CSS" attacks at

As the OP asked about "worst case", the answer is: "interception of the key, optional decryption of the intercepted data when a security layer like HTTPS is used and in the end it might lead to the abuse of the token".

Now, if the question would have been "how likely is it that this will happen", I would have answered: "pretty much unlikely, but that doesn't mean it can't happen".

But if you check the question again, you'll discover that that was not part of the question. So I won't go into statistics and probability calculations here. Besides, we're missing major parts of the "how and why" of the transmission, so no one can honestly give a definitive answer regarding the probability. That would be unprofessional, to say the least.

other forms of attacks

No matter how you do it - in the end, everything is unsecure and unbreakable crypto has yet to be invented.

Depending on the country, there can and will be a whole range of additional security problems involved... and I'm not talking about China! See how Tunesia kicked FaceBook security with something that's so simple, it should run shivers down your spine:

look at the question AGAIN

Don't take security questions lightly. You might comment against my answer and vote it down, but that won't make transmitting a Facebook token via TCP any safer!

Especially, as the OP does not indicate he is using any kind of security layer, we have to interpret it as if the FaceBook token is transmitted from IP "a" to IP "b" in an unsecure way!

A regular transmission of data using TCP is unsecure by definition for several reasons, of which I have merely scratched the surface of some.

I can only repeat: don't take security questions lightly.

share|improve this answer
your mixing up some things here.... see TCP is layer 4 as HTTP is a protocol on top of TCP and would be layer 7 – Rufinus Dec 12 '11 at 13:15
Tnx for down-rating because you did not read the question. Next time, don't stroke your ego by posting wikipedia links. Rather contribute something constructive. (1) This wasn't a question related to protocols, but about the safety of TCP transmission of data: a Facebook token. (2) Protocol is protocol, no matter the layer. They all use packets to transport data and those can be intercepted, causing security issues. For both TCP and HTTP a secured connection is a must to safeguard the data to transmit. Because of that, I explained and then concluded my answer with a two-letter "no" at the end. – e-sushi Dec 12 '11 at 15:12
@Rufinus: that doesn't really have much bearing here... – sarnold Dec 13 '11 at 4:19
@e-sushi : i read your answer. and besides 2 & 3 the outcome is wrong. to answer the question literally: YES. because TCP is per definition always unencrypted. the data transmitted via TCP may be encrypted. and as you said, the token itself is useless. besides. oauth 2.0 is always transfered via https. – Rufinus Dec 13 '11 at 11:56
You actually answer "YES"??? ROFL - saying "Yes, it's safe" is so... wrong! Security obviously is not your thing. Unencrypted data is not secure by definition. And saying the token itself is useless is scary. The token doesn't come all by itself, it will be transmitted from IP "a" to IP "b", providing ample retrievable information needed to abuse the token. It has been done in the past and I would be surprised if it doesn't happen again in the future. I really think you need to rethink security, but at least you managed to make me enhance my answer, which I regard to be constructive. UPDATED – e-sushi Dec 13 '11 at 21:35

No, this is not safe.

Access tokens are pretty sensitive. Anyone who knows the access token for a user can access the user's data and perform some actions as the user, for as long as the token is valid. For instance, anyone who knows the access token T can access the user's data by accessing

The details of exactly what the access token can be used for will vary. An access token is granted to an application, when the user authorizes the application (i.e., approves installation of the application). When the user authorizes the application, the user is asked to approve the permissions requested by the app. The access token alone then grants access to those permissions. Thus, an access token is enough to allow a bad guy to do anything that the app who was initially granted the access token was authorized to do. Depending upon what permissions were granted to the app, this might include things like reading the user's wall, getting information about the user, finding information about the user's friends, posting to the user's wall, or that sort of thing.

If you send the access token over an unencrypted TCP connection, then an eavesdropper who can capture the traffic you've sent can recover the access token and then use it to access the user's data or take actions on the user's behalf. That's not good.

For these reasons, you should treat access tokens as confidential, and you should never send access tokens over an unencrypted channel.

Facebook always uses HTTPS whenever it transmits access token. You should do the same: only send the access token over encrypted channels, like HTTPS; never send an access token over unencrypted channels.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.