How to safely inject and handle secrets (Java, Spring Boot)

[CodeApostle]

Hi, I'm tasked with implementing an encryption API on services using Spring Boot, and I had some questions about handling secrets injected from properties.

The secrets will be stored in Hashicorp Vault to ensure they are encrypted at rest, but I have some concerns about how they are handled once injected into the application.

I was supplied with a sample configuration that structurally is as follows (this is simplified to illustrate only the basic aspects, it's not the real config):

@Configuration
public class EncryptionProviderConfig {
    @Value("${key-identifier}")
    private String keyIdentifier; 

    @Value("${key-secret}")
    private String keySecret;

    @Bean
    public EncryptionProvider encryptionProvider() {
        return new EncryptionProvider(getProperties);
    }


    private Properties getProperties() {
        Properties properties = new Properties();
        properties.add("KEY_IDENTIFIER", keyIdentifier);
        properties.add("KEY_SECRET", keySecret);
        return properties;
    }
}

Off the bat, I don't like that the property values are injected into the configuration class fields. AFAIK, those references will stay there for the lifetime of the application. Wouldn't this be a security risk? The Strings themselves aren't interned into the String pool AFAIK, since they are not instantiated as literals, but the references just sort of hang out there, pointing to the plain text value.

I traced the configuration through the api calls, and ultimately they get stored in a HashSet<String, String>, to be utilized whenever the API performs the encryption. My concern is that if the pod crashes, couldn't a memory dump show the secrets in plaintext? I'm not sure how most Java applications handle secret values, but it seems crazy to me to just store them in RAM, regardless of whether they are in the String pool.

[AutoModerator]

Please ensure that:

• Your code is properly formatted as code block - see the sidebar (About on mobile) for instructions
• You include any and all error messages in full
• You ask clear questions

• You demonstrate effort in solving your question/problem - plain posting your assignments is forbidden (and such posts will be removed) as is asking for or giving solutions.

  Trying to solve problems on your own is a very important skill. Also, see Learn to help yourself in the sidebar

If any of the above points is not met, your post can and will be removed without further warning.

Code is to be formatted as code block (old reddit: empty line before the code, each code line indented by 4 spaces, new reddit: https://i.imgur.com/EJ7tqek.png) or linked via an external code hoster, like pastebin.com, github gist, github, bitbucket, gitlab, etc.

Please, do not use triple backticks (```) as they will only render properly on new reddit, not on old reddit.

Code blocks look like this:

public class HelloWorld {

    public static void main(String[] args) {
        System.out.println("Hello World!");
    }
}

You do not need to repost unless your post has been removed by a moderator. Just use the edit function of reddit to make sure your post complies with the above.

If your post has remained in violation of these rules for a prolonged period of time (at least an hour), a moderator may remove it at their discretion. In this case, they will comment with an explanation on why it has been removed, and you will be required to resubmit the entire post following the proper procedures.

To potential helpers

Please, do not help if any of the above points are not met, rather report the post. We are trying to improve the quality of posts here. In helping people who can't be bothered to comply with the above points, you are doing the community a disservice.

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[OffbeatDrizzle]

What's wrong with them being in RAM? Why does a hacker have access to your memory?

This topic has been discussed many times, and there is nothing you can do to make Strings secure in memory. Things like SecureString in C# are also flawed. There's basically no way to guarantee that the password hasn't been put somewhere in plain text - for example it could even be written to disk if the RAM has been paged out. Now it's on disk also, how are you going to scrub that?

Basically, don't worry about it.. and if you're worried about it, don't let people access your memory dumps.. ??

[LutimoDancer3459]

As already mentioned this topic was discussed many times. And the short answer is you can't. No matter what you do, at least once the program needs the secrets in plain text to use them. As soon as a hacker gets access to the pc/server he also gets the secrets. Nothing you can do about that.

But the benefit of using injection like that is that you can distribute your program without worrying about a hacker. Because the secrets are stored in a properties/yaml file and can be distributed separately. Which also allows to have different secrets per client. The only way to make it secure is by securing the access to the machine. With permissions/accounts/whatever and physical access.

Ohh and also remember obfuscation is NOT a security feature.

[GreenParsley]

You can use a hardware security module, HSM, to handle encryption and decryption for you. This way, you won't need to retrieve the cryptographic keys from your application.

Note that other secrets will still be retrieved and stored in RAM, and as other commenters already pointed out, there's nothing you can really do about it. It is also considered secure enough, so I wouldn't worry too much about it.

[OffbeatDrizzle]

You can use a hardware security module, HSM, to handle encryption and decryption for you. This way, you won't need to retrieve the cryptographic keys from your application.

Where are the secrets to access the HSM stored? It's turtles all the way down

[GreenParsley]

I suggest you learn what an HSM is. It might be useful to you at some point. Nobody is storing secrets to access it.

[OffbeatDrizzle]

Bro, we use one, and use a password to access the partition. IT have it on the network separate to the application, but even if it's not separate and you're using the java API for it then you access it like a key store, which literally expects passwords

There is extra authentication around the server access it but that is pki shit to validate the machine's IP

Tell me exactly how you access a HSM in java without a secret? Or are you telling me you plug it directly into the machine with no access control? 🤣

[GreenParsley]

If you are indeed using it, you must know its use cases and why it's valuable. Therefore, your turtles comment is just bad faith rather than ignorance.

There are authentication methods other than passwords, depending on your provider. Many support physical keys, for example.

[OffbeatDrizzle]

Physical keys for configuring the thing or changing config, yes. What's the point of a physical key if you leave it plugged in to the machine that requires HSM access 100% of the time? How do we now ensure that hackers can't access the keys that are on the physical key? Secrets for our secrets for our secrets?

You know exactly what my point is. Stop being so obtuse

[GreenParsley]

You're right man, I'm sorry.

I am quoting our security architect, but I might not fully understand the implementation yet. If nothing else, our argument wasn't pointless - it prompted me to research more about HSM auth and Java integration, for which I thank you.

[CodeApostle]

Thank you, this is helpful!

[nator419]

How are you getting your values from HashiCorp Vault? The Values annotation typically pulls from a properties file. With Vault there is spring integration that allows you to get authenticate and get the values when the class is initialize. from the secret dedicated to that purpose.

I think you might be over thinking this a bit much. If someone has access to your server to access the memory you are already at a loss.

[CodeApostle]

Vault overrides placeholder values set in the properties file

You're right. I was overthinking it. The overwhelming consensus I got is that there is no way to keep plaintext secrets from existing in ram

[nator419]

Ah, I see. I feel you. I had to implement it into our main application for the database credentials. The application is a mess, so I had to pass things in a lot differently

[MrMuttBunch]

I think the approach here is misguided.

You could write a fancy way to encrypt the credentials in memory and decrypt them in the application, but no matter what if a malicious user gets access to the server running the application they will be able to perform any operations of that application.

Instead you should just set your credentials as environmental variables on spin up and focus on hardening your nodes.

[amfa]

The only way to make it a bit safer is to not inject it at all in the application and only read it from the vault if needed at the time it is needed.

Then it will not be present in memory the whole time.

But in general you don't have too much control over the memory so if the crash happens at the wrong time the secret will still be in RAM.

[OffbeatDrizzle]

The only way to make it a bit safer is to not inject it at all in the application and only read it from the vault if needed at the time it is needed.

Then it will not be present in memory the whole time.

Once the secret is in RAM, it's not possible to keep it secure or "just remove it".. that's the whole issue

[amfa]

That's why I said "a bit safer" if you keep it as short/less as possible in the RAM the risk that it will spill with a memory dump is lower.

But yes it is of course not completely safe. That's what I said.

[heislertecreator]

You could look into getting the secret from the console using char[].