Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I have heard some say it isn't but they never suggest an alternative. Is this true?

UPDATE Is it possible to store this external from application and have it called?

share|improve this question
    
What do you mean by "application keys" and "ids?" These terms could have many potential meanings. –  syrion Apr 6 '11 at 13:27
2  
@syrion It really depends on the API. Some call them client ids, application ids, API key. Basically the code they give you that allows access to an API. –  loyalpenguin Apr 6 '11 at 13:32
    
What kind of application is this? Is this a Desktop app or a Web app? Is this going to run on client's machines? –  Shamit Verma Apr 7 '11 at 8:36

6 Answers 6

up vote 5 down vote accepted

In Enterprise environments, storing any kind of credentials (Keys / usernames etc) in applications is highly discouraged.

All such credentials should be stored on:

  1. Config file located on a file server OR
  2. Can be served via a Web Service

This way you can enforce ACL* on these. And only the user id running these apps should have access to these. For example, you can create user ids "accounting_producion" or "accounting_qa". And app should run as these users. And only such users + support users should have access to configs.

And any change can be quickly propagated though all instances.

ACL -> Access Control Lists

share|improve this answer
    
So, if you are storing your api keys in a web service, where do you store the key to access said presumably secure web service? –  Wyatt Barnett Apr 6 '11 at 13:56
1  
You should not have to store Keys to access the web service. Application should use OS level authentication to authenticate itself to web service. E.g. NTLM or Kerberos. For example, when user logs onto Desktop, user would not be prompted again for password in Outlook. Outlook would use the same auth information to authenticate end-user to Exchange. –  Shamit Verma Apr 6 '11 at 14:01
    
Well, you know not everyone is running on windows these days . . . –  Wyatt Barnett Apr 6 '11 at 14:08
    
Windows is just an example, OS does not matter. Windows and Unix both use Kerberos. So, if App is running on Linux (Or Solaris or BSD or ...) it would still supply auth tokens generated by OS. And Web Service would authenticate based on those tokens. –  Shamit Verma Apr 6 '11 at 14:17
    
@Shamit Verma this is exactly what I wanted to know. Are there any resources on accessing a key through a web service? –  loyalpenguin Apr 8 '11 at 2:40

Consider what would happen if you update a key or an ID - do you really want to recompile and redistribute a new binary?

It is usually much easier to keep this kind of data in a separate config file which can be updated more easily.

share|improve this answer
    
Recompiling a binary just to change an ID/key seems a bit much, but deploying it wouldn't be any harder than deploying any other update to the program. –  FrustratedWithFormsDesigner Apr 6 '11 at 13:31
1  
Depends on how you want to handle such updates, if your app was able to get it's config over the web then updates would be trivial. No reason an app can't alter it's own config. Or the user could edit the file. Depends on the scenario, but there are plenty of cases where it is much easier. –  Steve Haigh Apr 6 '11 at 13:34

I'd vote definitely in the configuration -- you'll probably want to, at the least, have a different key for dev and/or staging. Having it in the configuration file makes the most sense as this is typically different for each environment.

Note that if we are talking about an interperted vs compiled environment, said configuration file could be whatever language you are using rather than xml/yaml/json/.ini/whatever format you just made up.

share|improve this answer

In light of your comment, consider this question in terms of an API key: are you going to assign the same key to every user of your API?

Consider a scenario in which you are being attacked. You can isolate the source of the attack by IP address, and see that it's coming from a company with access to your API key. You must assume that their key has been compromised. However, if your API key is hard-coded, you will need to change the API key in the application, redistribute the application to every customer, and make sure that any of the customers' applications/services which rely on your API have been modified to deal with the new API key.

This is a cost for both your company and your customers; it could influence your relationship with your customers negatively.

If, instead, you store your API keys in a database, one per customer, you can simply run a single SQL query and fix the problem.

share|improve this answer

I generally try to get everything which is environment dependent out of the application. I haven't run across a configuration item such at you listed which needs to be in the application for technical reasons. It looks like you are looking for your options.

Many items are well suited to being placed in a configuration files. The rest of the items should work well when placed in the applications database.

Some run-time environments contain variables and/or command line arguments which the application can read. These are a good choice for configuration items which you may need to override for a particular run.

Placing configuration items in the application means you need to have environment specific compiles. This can result in problems which can only be replicated in one environment, because that is the only environment which has the broken code. It also risks that the wrong version will be built for the next environment.

share|improve this answer

Of course it is - especially if it's a VM-based decompilable language, like Java or C#... :)

share|improve this answer

Your Answer

 
discard

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

Not the answer you're looking for? Browse other questions tagged or ask your own question.