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?
-
What do you mean by "application keys" and "ids?" These terms could have many potential meanings.– asthasrCommented Apr 6, 2011 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.– EdwardCommented Apr 6, 2011 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 VermaCommented Apr 7, 2011 at 8:36
Add a comment
|
6 Answers
In Enterprise environments, storing any kind of credentials (Keys / usernames etc) in applications is highly discouraged.
All such credentials should be stored on:
- Config file located on a file server OR
- 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
-
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? Commented Apr 6, 2011 at 13:56
-
1You 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. Commented Apr 6, 2011 at 14:01
-
Well, you know not everyone is running on windows these days . . . Commented Apr 6, 2011 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. Commented Apr 6, 2011 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?– EdwardCommented Apr 8, 2011 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.
-
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. Commented Apr 6, 2011 at 13:31
-
1Depends 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.– SteveCommented Apr 6, 2011 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.
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.
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.
Of course it is - especially if it's a VM-based decompilable language, like Java or C#... :)
