We have to use ssl certificate for our rest web service which are created through springboot application.
Now, what I came to know that password is necessary in order to use a certificate. So we are changing our available .pem (without password) to .p12 (with password) using openssl. Now we have to provide spring this password.
Problem is the overhead which comes with introducing any new password.
We cannot hard-code this password in our application.properties due to bad design. So we are thinking of finding out the other ways to use password in application. So far I can think of below options. which one is better one and why?
Rather then setting password in application.properties, set it from java code. (I am not sure it will be set as environment variable or system variable)
use environment variable to store the password.
use any text file which stores the password (not preferred again due to bad design)
you can achieve your scenario in the following way.
i am posting sample example.\
In Properties File:
spring.datasource.url=${db.url}
spring.datasource.username=${db.username}
while starting the project,
you can give the following command:
java -jar -Ddb.url=jdbc:postgresql://localhost:5432/postgres -Ddb.username=postgres sample.0.0.1-SNAPSHOT.jar(your jar name)
option 3 seems feasible, but instead of storing it in a plain text file, you can encrypt the file, and put a decryption function in the application when reading the file.
For the provided options, i would go with the option 2, by using environment variables it will be easier to provide and change the password even in containerized environments and clouds.
But you can also consider other options, like using a safe k-v storage like Hashicorp Vault or etcd.
Note that using Vault or etcd, you can also provide and change the certificate dynamically, instead of shipping it with the application.
I can think of 3 ways you can do it
1. You can define password property only in application.properties but pass
the value of the property during application startup.
java -jar -Dmyapp.password=YOUR_PASSWORD myapplication.jar
2. You can put encrypted passwords in application.properties and pass the decryption key during application startup. Jasypt plays very good with spring boot.
java -jar -Dmyapp.decryptKey=YOUR_KEY myapplication.jar
3. You can use spring vault
Related
I have a simple java web service that uses javalin framework. I want to deploy it in multiple environments, so the env variables are different for each deployment.
I basically want to read
application-env.yml
keystore:
path: ${KEY_STORE_PATH}
password: ${KEY_STORE_PASSWORD}
from application-env.yml without using Spring.
And then use them in java.
Properties properties = PropertiesLoader.loadProperties();
System.out.println(properties.getProperty("keystore.password"));
// ${KEY_STORE_PASSWORD}
System.out.println(System.getenv("KEY_STORE_PASSWORD"));
// hunter2
How do I get hunter2 from properties?
EDIT:
i didnt get what I wanted, ended up doing this:
https://stackoverflow.com/a/73539823/2948875
You could use something like SnakeYAML, ie https://www.baeldung.com/java-snake-yaml
I have stored the password of MongoDB in spring.data.mongodb.password property in application.yml file in my spring boot project. I need to encrypt it so that it is not directly accessed by anyone. I do not intend to do any code changes for it but want to achieve it by some kind of spring boot configuration.
The properties file should never be accessible by anyone (who uses of course the app)... Given that for granted, then I guess you mean to the other people working on your project, in that case I guess a possible solution would be to use BCEncryptor to encode a password and store it either in the properties file or on a side DB and then decrypt it at the launch of the application, through a configuration class or XML.
In any other case you could create a side user in MongoDB giving that use only the permissions you want.
But still, I wouldn't really see the use of it, because if someone have access to the backend of your application...
The issue got resolved. The problem was with the jasypt version. I was using jasypt-3.0.0 and it worked on 2.0.0. The full steps of configuring jasypt in the project can be found here :
https://medium.com/#mail2rajeevshukla/hiding-encrypting-database-password-in-the-application-properties-34d59fe104eb
I have passed the key in application.yml itself as the 3 mentioned methods were not working in my case.
jasypt:
encryptor:
password: secretkey
I am using Xero's Java SDK to build my application. My application is now facing a requirement of having to work with several Xero private apps, therefore I need to manage and performing authentication (OAuth) via the key certificate file and appropriate consumer key and secret.
I was thinking to very simply store these details in a database table and retrieve them appropriately more or less as in the following:
// create a Xero config instance
Config config = JsonConfig.getInstance();
// build config file - details will be obtained from database
config.setConsumerKey("key");
config.setConsumerSecret("secret");
// this line will have me authenticate with the Xero service using the config file built
XeroClient client = new XeroClient(config);
The problem with this approach is that I am not pointing at the public_privatekey.pfx key file which is another essential element required to authenticate.
The reason why I am not doing so is that the SDK does not seem to support this using the Config instance as shown above - there is no option for me to select the appropriate public_private.pfx file (and neither an option for me to just load the contents of the file). It doesn't make sense to me that an SDK would be missing a feature, therefore questioning my approach; have I overlooked a detail or am I approaching the problem incorrectly?
Take a look at the read me under the heading Customize Request Signing
https://github.com/XeroAPI/Xero-Java/blob/master/README.md
You can provide your own signing mechanism by using the public XeroClient(Config config, SignerFactory signerFactory) constructor. Simply implement the SignerFactory interface with your implementation.
You can also provide a RsaSignerFactory using the public RsaSignerFactory(InputStream privateKeyInputStream, String privateKeyPassword) constructor to fetch keys from any InputStream.
Recently I have gone through Jasypt API to secure the property file entries. As per Jasypt, in order to decrypt the entry in the property file that was enclosed with ENC(..), we need to use a secure password, a secret key, as shown below (Not a web application):
encryptor.setPassword("jasypt"); // could be got from web, env variable..
Of course we can configure such password using
org.jasypt.encryption.pbe.config.SimplePBEConfig setPassword()
But my question, if we extract the jar file, 3rd party could be able to find out the secret key. How could we ensure security in such cases?
Thanks in advance,
JK
secret key should be stored in environment variable outside the application.
For example, in your spring configuration file:
<bean id="environmentConfig" class=
"org.jasypt.encryption.pbe.config.EnvironmentStringPBEConfig"
p:passwordEnvName="APP_ENCRYPTION_PASSWORD" ...
Now, add APP_ENCRYPTION_PASSWORD in the env variable either in OS or app server.
I'm starting to use cloudify and in the spirit of DevOps where infrastructure is code I want to have the passwords stored in a safe and centralized place.
It seems to me that I am supposed to put the credentials in the .properties file of the relevant service but versioning the plain password seems like a bad idea and not versioning it also seems like a bad idea (code which is unversioned).
I know chef has encrypted data bags and I was wondering if cloudify has something similar? If not is there a different best practice I should be aware of?
Thanks
With the upcoming Cloudify 2.3.0 release, you will be able to add overrides to property setting in the install-* command line. So your recipe should include a properties file with a default, possibly empty, password. This password should not actually do anything.
When you actually install the service, use overrides to set the actual password. This will keep the clear-text password out of your versioned properties file.