13

I have an open source project that uploads files to DropBox among several file hosts. Right now I am screen scraping for DropBox. To use their API, I have to hardcode a SECRET KEY provided by them to me for OAuth authentication. But I'm afraid that the key won't be secret if it is visible plainly for anyone to see.

It is 'possible' for someone malicious to use my key to upload a virus to a user's account (who already allowed access to my app) that will spread to their pc (if they had desktop sync enabled) and to others' pc (if they had shared folders) and so on. :O

I found this unanswered question that has the same problem as mine.

But I would like to know generally how one would hide confidential data in an open source project.

I have one idea.

  • Have a placeholder in the source code like "<SECRET KEY HERE>" and fill it only when building binary for release? (yuck!)

Any decent idea?

Community
  • 1
Vigneshwaran
  • 759
  • 6
  • 16
  • 1
    That's really the only safe way to do it. You could use pgp encryption to encode your secret key as well, then only you could decode it, but why bother publishing it at all. – Prescott Dec 30 '12 at 08:38
  • Might want to check out this question: http://programmers.stackexchange.com/questions/180957/typical-way-to-share-database-connection-for-open-source-project-without-reveal/180973 - it's not about DropBox API keys, but the general message is the same. – tdammers Dec 30 '12 at 15:22
  • git-crypt has been made for you :) https://github.com/AGWA/git-crypt – nha Jun 11 '14 at 12:24

3 Answers3

14

The basic idea is that you do NOT check-in confidential values in the code or in the compiled binary. Especially if the project is open source you really shouldn't. There are several configuration strategies you can take in order to do so:

Placeholders in code (hardcoded values)

Placeholders in code - as was suggested - which is most sane and easiest to do in dynamic programming languages as the code is easy to change (without needing to compile). I've seen a lot of open source projects do this such as MediaWiki with it's LocalSettings.php.

The downside with this strategy is that the key is hardcoded. So if the program is distributed as a binary then having the key hard-coded does not make it particularly maintainable.

Configuration Text Files

You can also do this by implementing configuration text files, i.e. the program/application searches for a configuration file and reads values from it. You can check-in a sample configuration with placeholders but have the actual configuration local in your machine.

In your case you can create a key.conf text file with the actual key, let the program use that file and let it be ignored by version control. You can, for being helpful, check in a key.conf.example text file with a bogus key and check that-in. Make sure your program/application makes an helpful error message for the user to add the actual key in the correct file.

Some programming languages have APIs that provide this automatically for you, such as:

If your application is a database app, then consider putting the key or other configuration variables in the database. It is the same as the configuration text file above but you put all configuration variables such as the key in a database table instead.

Through preferences view or a Back Office app

If the program is a window or a web application with views then you can also let the application create the configuration file, through a preferences view of sorts. That way you don't need to check in an example config file as suggested above.

MediaWiki solved this similarly by auto-generating the LocalSettings.php file in an initial installation process.

Admittedly this is not an option for programs that solely run as background processes, services or daemons. However that's why you create seperate GUI projects for these to create a point-of-entry for administration and preferences settings, in web apps usually called a Back Office application.

Spoike
  • 14,765
  • 4
  • 43
  • 58
  • One thing to note here: Having the application itself modify its own configuration settings means the settings file has to be writable by the application's user, which in turn increases attack surface, so you should think hard whether you really need such a UI. – tdammers Dec 30 '12 at 15:20
2

The easiest way is to simply not publish confidential data. Some options:

  • Use a placeholder like in the question.
  • Use a header file especially for the key, don't commit it to source control, and only privately distribute it to trusted parties.

I've used the second option for open source development because it means you don't have to worry about filling in the details just before build, or having one change to remember not to commit.

Hugo
  • 3,669
  • 2
  • 25
  • 40
2

If someone has the source code (or byte code that can be reverse engineered) then they WILL be able to get the secret key by running the code in a debugger, and putting a break point at the point where you send the key.

You can make it a little harder by supplying a precompiled C library that talks to drop box, with the key encoded in that, but there are still plenty of ways in which keys will leak out (i'm thinking strings for example).

The only safe way that I can think of doing this, is to provide a web service that does the posting to drop box. That way the secret key remains on your server under your control. The hosting and bandwidth costs mean that this solution is less than ideal for a free application, but the added bonus is that your server can authenticate the clients properly before relaying their files being sent to dropbox.

Michael Shaw
  • 9,915
  • 1
  • 23
  • 36