3

Where should I store credentials for my java application to access third party services?

The credentials are not specific per user on my application. They are for accessing a web service my application is consuming. I know enough not to hard code them into my application, but where and how do I store them? I also assume they will need to be encrypted.

Mark W
  • 5,824
  • 15
  • 59
  • 97
  • How critical is that information? Will it break all your installations of that app at all your customers when the credentials should be compromised? How much damage could be done through that 3rd party ws? If you were to encrypt those credentials, where would you save the key for decrypting? ... Would you have one key for all installations or a new one for each customer? – Fildor Dec 07 '16 at 09:42
  • I would say the credentials are highly sensitive. – Mark W Dec 07 '16 at 09:53
  • @Fildor The credentials are only for app to app communication. They are not relative to a customer. ApplicationScoped you might say. There is one set per environment (eg production, test) – Mark W Dec 07 '16 at 09:55
  • I see that. I was referring to encryption. You could encrypt the same set of credentials with one single key for all your installations or encrypt with a new key per customer ... which doesn't make too much sense. They will still be compromised if one of them should be cracked. Does the 3rd party use any sort of security measures? Like OAuth2 or is it plain-text-user/pass? – Fildor Dec 07 '16 at 09:58
  • I would expect the third party to implement their own security measures. The credentials are for access to the third party web service, they are not submitted in any web service calls. – Mark W Dec 07 '16 at 10:01
  • Can you elaborate a bit on the 3rd party and what those credentials actually do? I guess it will be some kind of application-api-key, right? – Fildor Dec 07 '16 at 10:03
  • @Fildor I want to avoid giving away system information here. Its just a question about how to store a single credential (per environment) which is not associated per user (as most questions are). The credentials gain access to a third party web service. – Mark W Dec 07 '16 at 10:14
  • 1
    What I am aiming at is that you can do different stuff if the service uses hashes or even salted hashes etc ... so you could save and deploy just a hash instead of the actual credentials ... personally if this is really highly sensitive, I guess I would use some sort of asymmetric encryption and make a separate binary to compute the public key. It's still kind of security by obscurity but would increase the effort needed to crack it. In the end - if you need the credentials in "plain text" at some point there is always the threat of someone inspecting you memory ... so you won't get to 100%. – Fildor Dec 07 '16 at 10:22
  • Or in other words: If the aggressor has access to the customer's server system or if he *is* the customer, it will increase your effort to reach a reasonable level of security immensely. – Fildor Dec 07 '16 at 10:26

4 Answers4

2
  • Db
  • .properties file
  • configuration class with constant

Spring have nice functionality with @Value annotation that can auto-magically inject value from .properties file (under resources folder) with a given key.

I use that because in my case I have different key values in multiple app instances and db would require little more complexity, and furthermore I don't make unnecessary queries to db.

On security basis if attacker can read files on your server than he can easily read your db so that don't play a part here. It can be stored in any file on the system.

On the other hand you can have configuration class with

public static final String SECRET_KEY = "someKey"

Zildyan
  • 1,261
  • 9
  • 11
  • 3
    I don't see any security benefit here over hard coding the credentials into the app? – Mark W Dec 07 '16 at 10:03
  • Because security is a global problem for entire app and not for particular key/value.. this way you get decoupled implementation and can easily manage key values. And these are three ways to do that. – Zildyan Dec 07 '16 at 10:08
  • 3
    I guess OP's problem with that is that credentials would still be in "plain-text" ... you could just open that properties file and read the credentials, for example. – Fildor Dec 07 '16 at 10:13
  • Its possible to reverse engineer an application from it's binary without source code. So hard coding a password into an app would be very bad practice. – Mark W Dec 07 '16 at 10:17
  • Encription is not neccessary in my point of view. I have secret key for payment provider in plain text, security is done on the level of app and server. If you encript that you are hiding that value from yourself – Zildyan Dec 07 '16 at 10:17
  • Here you go: same question same answer http://stackoverflow.com/questions/13991100/where-do-you-store-your-secret-key-in-a-java-web-application – Zildyan Dec 07 '16 at 10:19
  • @Zildyan I disagree. What if someone (not necessarily an attacker, but perhaps one of many junior devs/ infrastructure support) with access to the server were find the password. I think encryption is a necessity for sensitive credentials. – Mark W Dec 07 '16 at 11:24
  • Ok, you can encrypt it - but then you must place somewhere encryption key that leads you to the same problem. – Zildyan Dec 07 '16 at 13:56
1

.jar file is best way to store all credentials.

  1. Create interface where store your credentials as a final String
  2. convert interface to jar file
  3. Add that jar file in your build path
  4. Implement this interface where u use credentials, and access String object in which u stored credentials.
Pranay Kumbhalkar
  • 701
  • 6
  • 18
0

To build upon @Zildyan's answer, comments and references to other answers.

There are a few options for where to store:

  • Database
  • Properties file
  • Constant (hard coded)
  • File system (away from application)

As for how to store:

Depending upon sensitivity. Credentials could be stored in plain text (low sensitivity) or should be encrypted (high sensitivity).

It should also be noted that using a combination of encryption and separating the credentials from the source you would restrict internal access to the credentials.

Some examples

  • a password stored in plain text may be added to source control and read by anyone with access to the source control.
  • An encrypted password with decryption code would be easily available to anyone able to run the code.
  • A plain text file stored on the server may be accessible to anyone with access to the server.
  • An encrypted file stored on the file system may only be accessible to sys admins and the decryption method available to devs.

The same goes for storing in a database and who has access to that database.

Mark W
  • 5,824
  • 15
  • 59
  • 97
0

JNDI

Per Wikipedia:

The Java Naming and Directory Interface (JNDI) is a Java API for a directory service that allows Java software clients to discover and look up data and resources (in the form of Java objects) via a name.

Your enterprise likely has a JNDI-compatible directory service established. You would ask the sysadmin to include an entry for your particular credentials.

If you are self-administering, then your Java EE (now Jakarta EE) should have a JNDI-compatible server built-in. Learn to configure it, and add the entry for your particular credentials.

Basil Bourque
  • 303,325
  • 100
  • 852
  • 1,154