6

I am aware that these questions has been asked before several times separately, and most of the answers I've found are "Python is not easy to obfuscate, because that's the nature of the language. If you really need obfuscation, use another tool" and "At some point you need a tradeoff" (see How do I protect Python code and How to keep the OAuth consumer secret safe, and how to react when it's compromised?).

However, I have just made a small Python app which makes use of Twitter's API (and therefore needs OAuth). OAuth requires a Consumer Secret, which is to be kept away from users. The app needs that information, but the user should not be able to access it easily. If that information cannot be protected (and I am using obfuscation and protection as synonyms, because I do not know of any other way), what is the point of having a OAuth API for Python in the first place?

The question(s) then are:

  • Would it be possible to hardcode the secret in the app and then obfuscate it in an effective manner?
  • If not, what would be the best way to use OAuth in Python? I have thought of "shipping" the encrypted consumer secret along with the app and using a hardcoded key to recover it, but the problem remains the same (how to protect the key); having the consumer secret in a server, and have the application retrieve it at start up (if information is sent unencrypted, it would be even easier for a malicious attacker to just use Wireshark and get the consumer secret from the network traffic than decompiling the bytecode, plus how could I make sure that I am sending that secret to my app and not to a malicious attacker? Any form of authentication I know would require having secret information in the app side, the problem remains the same); a mixture of both (have the server send the encryption key, same problems as before). The basic problem is the same: how can you have something secret if critical information cannot be hidden?

I have also seen comments saying that one should use a C/C++ extension for those critical parts, but I do not know anything about that, so if that were the answer, I'd appreciate some extra information.

user2891462
  • 3,033
  • 2
  • 32
  • 60
  • 1
    Who is "the user" in this question, a customer of yours? (You suggested "shipping" the application along with a key, but I'm not sure if you meant that literally.) – Kevin J. Chase May 12 '15 at 15:33
  • The user is just myself, this is not a serious project. I was wondering how someone who actually ships (for example, makes it available in their website) a Python application using OAuth does it. – user2891462 May 12 '15 at 15:38
  • Is this related to the issue discussed [here](http://blog.codinghorror.com/keeping-private-keys-private/)? – TigerhawkT3 May 12 '15 at 18:22

3 Answers3

0

If you want to deploy on servers (or laptop) you own, you can store secrets in env var or files. If you want to deploy to user, suggestion is that you, or your user should register an API key, generate ssl key, or similar.

vagoston
  • 171
  • 8
-2

You can code your own simple symetric crypt fucntion with a lot of data manipulation to make it harder to reverse.

psyskeptic
  • 286
  • 2
  • 4
  • 17
  • Care to develop more? AFAIK, implementing your own cryptography functions is highly inadvisable, and the problem would still remain: where do I safely store the symmetric key? – user2891462 Jun 01 '15 at 10:36
  • Coding your own very simple but hard reversible crypt function takes about 1-3 hours depending on your fantasy ). Beside Khnowing key doesnt reveal data without knowning encryption algoritm. Also you can use random keys, generated on the fly. – psyskeptic Jun 13 '15 at 17:23
-2

It is unclear why you'd need to ship your OAuth key with the script. That would mean giving anyone access to your Twitter account, whether or not the key itself is obfuscated inside the app.

The more typical scenario is that you develop some Twitter client, and anyone who wants to run it locally will have to input their own OAuth token before being able to run it. You simply do not hardcode the token and require any user to supply the token.

deceze
  • 510,633
  • 85
  • 743
  • 889
  • 1
    If I understand Twitter's OAuth correctly, the consumer secret and the consumer key identify my client to the API. All instances of a client will share them, and it's the access token what is different for each user (see the examples in https://dev.twitter.com/oauth/overview/single-user). I wouldn't be giving them access to my account, but they would be able to impersonate my client in the eyes of the Twitter API. – user2891462 Aug 21 '17 at 08:56
  • Yes exactly, anyone you're giving your OAuth token to, whether directly or indirectly by embedding it into an app, can impersonate you as far as Twitter is concerned. So there's the bigger problem IMO; is this *really* something you want to do? (Hint: no, likely not.) – deceze Aug 21 '17 at 08:58
  • Well, the first thing the client needs to do is to authenticate to Twitter in order to make use of the API (see https://github.com/bear/python-twitter#api), and it needs the consumer key and secret for this. There is no way to work around this as far as I know. What schema would you propose for a Python-based Twitter client which does not leak the secret? – user2891462 Aug 22 '17 at 06:22
  • This is an example of what such apps typically do: https://github.com/shichao-an/twitter-photos#setup – deceze Aug 22 '17 at 07:34
  • That's what I did when I uploaded the code to GitHub. However, my question is: could one make a Python-based Twitter client to be widely available for people without requiring them to register their own app in Twitter? – user2891462 Aug 22 '17 at 07:45
  • 1
    In that case I'd highly recommend a server to go with the app, where the server stores the secret and is part of the OAuth flow. I would never embed secrets in public code in any form, because there's no way to completely obfuscate them. – deceze Aug 22 '17 at 07:47