The preferred method of keeping passwords/api keys secret on heroku is to set config values via the heroku commandline application. The following example taken from a heroku dev center article

(The below example, and my entire answer relate to rails apps)

$ cd myapp
$ heroku config:add S3_KEY=8N029N81 S3_SECRET=9s83109d3+583493190
Adding config vars and restarting myapp... done, v14
S3_KEY:     8N029N81
S3_SECRET:  9s83109d3+583493190

Then reference these config values in your code using the ENV[] variable

AWS::S3::Base.establish_connection!(
  :access_key_id     => ENV['S3_KEY'],
  :secret_access_key => ENV['S3_SECRET']
)

This way your sensitive passwords are not stored in the git repository. (Note: When running the app locally, set these values in your .bashrc file

Also, I’m not sure what type of application you are running, but in Rails, heroku does not use your database.yml file, it simply sets your database username/password according to your app settings. So you can avoid saving those credentials in git

Also, also, if you are running your own application and want it to remain private, a great alternative to github is bitbucket which offer free private repositories.

Several ideas… Public Key Cryptography is the most flexible answer.

Obfuscation (for code only)

For the parts of the code you want to hide, could you put them in a different project, compile them, and check in only the compiled code, not the source? This is not encryption and not suitable for encrypting passwords or keys. People can still reverse-engineer your compiled code, but they don’t get the source.

Private GIT repository

Does it have to be a public git repository?

Server Storage

Can you store this info in a protected file in the home directory of the user account the application runs under? I would copy the way ssh does this with ~/.ssh/id_rsa and a chmod of 600. Failing that, an environment variable could be used. You need somewhere on the server to store some kind of key, or there is no way you can protect anything.

Symmetric Cryptography (just for you)

If you are the sole developer, you could put a key on the server and have that same key on your machine and use a symmetric encryption scheme to protect some data like a password or certificate. Sharing a symmetric key with friends gets messy.

Asymmetric Cryptography (for multiple developers)

If other developers need to check secret things into a public git repository, , public-key/private-key (asymmetric) cryptography was made for this kind of thing. Install a private key on your your server (do not check it into source control!) and generate a public key from it. Encrypt your secret data using the server’s public key. Only the server can decrypt that data using its private key. You can even check the public key into source control so that other people can encrypt data using the same public key and only the server can decrypt it.

Tool

Openssl is probably the only cryptography tool you’ll ever need. Do not write your own cryptography algorithm or your own implementation of a published algorithm.

Closing thoughts

If the “server” is a web server that uses https, then you should already have a secure keystore of some kind on the server to store the private key in. It’s kind of mind-blowing that a hosting company wouldn’t make allowances for this. Maybe they have some hints on how others solve the challenge you are facing?

If you want to run your code on Heroku, you have to give it to them – you can’t keep it “secret” from your hosting provider.

So far as public git repositories go, if your project is open source but you don’t want to share hosting details, you would need to maintain a private fork of your project for the purposes of deployment.

You should not be hiding parts of the code. The security of your system should not rely upon the secrecy of the code; that’s known as “security through obscurity”, which is frowned upon by security experts because it works very poorly.

Instead, passwords, crypto keys, etc. should be kept separate from the code. Store them in a separate configuration file or configuration value which is read by the code. You don’t need to store them in git.

Important: Never hardcode cryptographic keys, passwords, or other secrets in your source code! That is very bad practice.

See also:

• How do open source projects handle secure artifacts?

• Password in file .php

• Standards for encrypting passwords in configuration files?

• Open Source and how it works for secure projects?

• How to protect ftp account information in the source code of a program

• Is it a secure way to declare DB parameters in htaccess rather than in a PHP file?

Plug: IT Security.SE is a great place to ask questions about security!