Should a closed source website keep a secret key in its source?

Question

Various APIs (such as Facebook or Amazon S3) require a secret key to authenticate access to the service. Obviously, if source code is public, the key should not be in the source! What about for a closed source website?

Answer 1

My recommended practice is not to put keys in source code. The best option for your particular situation depends on some of the details.

Generally, the preference is to keep the key in a separate file that is not stored in the source code repository. You can even have a secrets directory if you like and store the keys there. Generally you issue the keys to appropriate users -- those who need to make final builds or builds that can test the functionality that requires the key.

If you have individuals who work with your source code who are not fully trusted with the keys (for example, if outsourced programmers add to your code) you can rig the code to operate in a fallback mode if it doesn't have the secrets. This may or may not be appropriate to your situation.

I should point out that there really is no good way to keep the key secret if you distribute the object code. This method really should only be used in programs that are not just closed source but closed distribution. If you have to do some obfuscation, not just the key but the obfuscator should be in the secrets directory and its distribution restricted.

Answer 2

Source code life cycle and key management may conflict. For instance, you may (should) use a versioning tool such as Subversion to store the successive modifications you perform on the source code; if you put the secret key in that, then the key will be stored as well. Basically, if you store the key in the Web site source code, then you need to make the source code exactly as secret as the key; a key is small and, as such, deemed easier to keep secret (e.g. it is conceivable to write down a key on paper and store the paper in a safe, because typing it back can be done in a few seconds), whereas the source code for a whole site is much more cumbersome. If you store the key in the source code then, all of a sudden, obtaining a copy of the Web site source code becomes a very valuable target for attackers.

Answer 3

If with "in the source code" you mean as part of logical code in a file, I would agree with the others: Don't do it. Speaking for PHP, then pieces of your code might show off in debug reports, possibly even on the website (at least in dev view).

The other two options are - a dedicated config file in the programming language your are using for the project. You might then include it where you need it or better use something like the Registry design pattern. The advantage is, that the file is interpreted when called directly and will not output the secrets. - a dedicated plain text conif file. This has to be protected from direct calls, for example by placing it outsit the DocumentRoot.

I mostly go with the latter and generally only place a frontend controller in the DocRoot and leave all libs, configs, most data etc. parallel to that.

Answer 4

The first answer popped in my head is NO, it's not right practice.

Though, sometimes people are supposed to follow practices which are not absolutely perfect but required for the early-release, customer-closed-requirement, or some other miSf(H)IT.

So, if in such situations please try to take few points into consideration as:

• NOT as PLAINTEXT most important

  • encode it, salt it..... do whatever you can

• Don't embed it in Source Code everywhere

  • make a config file with it's detail in it, and read from it

  • assign config file permission to be "read only" and only by user required

Answer 5

It depends. Who has access to the sources/binaries? If you can secure access to the sources sufficiently, there's not much wrong with having the key in the sources from a security perspective. I'd still advise against it. Firstly, such an approach decreases maintainability and secondly, you can have user specific keystores on most systems which allow you to read such keys from cryptographic containers. That way you can secure the access to those keys even more and only certain users or groups can retrieve them.

But if someone skilled launches a dedicated attack and has root access or even physical access to the machine, then he will be able to retrieve the password sooner or later. So some people started to encrypt such routines with a key that needs to be obtained from a different place during application startup/execution. This can introduce a second line of defense as you can deny access for applications which are untrusted from a different location. But for most applications, I consider that an overkill.