I currently develop web application using spring boot, i want to ask what is the best way to store salt key for encryption
Currently i create encryption util class and i still doubt about how to store salt key.
i have to 2 options :
1. i create static final property on my encryption util
2. put at application.property file
or you have another suggestion
thanks
The simpliest is option 1 and it's IMO more secure than option 2 if you planned to put your key is in plain text in application.properties.
But the best would be to add your key in application.properties (option 2) and encrypt it, for example, with jasypt .
You can find samples with Spring boot here
Related
All is into the question. I'm using spring boot 2.2 and I follow the documentation to set HTTPS (see the doc chapter here). In this example there is two parameter to define the key password. But in fact the password of my key need to do the same in that to parameters to work... An idea about why spring define two password entries ?
Thanks in advance for explainations ;)
Additional informations: I have the same comportement with .p12 and .jks key.
This is not spring Specific but a standard one.
Keystore is a binary file that contains a set of private keys.
Private key represents the entity to be identified with the app, such as a person or a company.
See this thread : Keytool's -storepass vs. -keypass -- Why 2 passwords?
And
What's the difference between Key store password and Key password in Android Sign Certification?
Instead of encrypting individual configurations in YAMLs, I want to encrypt entire YAML.
Is there any way to achieve this in Spring boot? I know the requirement looks
unrealistic at the moment, but we really required this.
I am using Spring Cloud Vault to store an API Key in production.
From reading the spring.io blog it appears I can use
#Value("${apiKey}")
String apiKey;
to access that key in vault.
This is fine when in production, but is there a way that I can set a default value/ some other way of setting up an apiKey that can be used locally for development? (preferably outside of vault if possible)
As explained in the Spring Boot Reference Guide several sources of configuration properties are consulted. It doesn't really matter where the value for apiKey comes from.
You have at least 3 options:
Set it in the environment,
Pass it as an argument with --apiKey=<your-api-key> when starting the application locally
simply place it in an application.[properties|yaml] used for local development.
Either way the apiKey property will be resolved locally without having to use the vault.
You can set a default value (if the apiKey is not found ) like this :
#Value("${apiKey:MY_KEY_HERE}")
where MY_KEY_HERE is the default value.
I am currently configuring my CAS Server v5.0.2 to use Database Authentication, particularly using the Encode method, using the CAS properties file. Below are the relevant property configurations from the properties file:
cas.authn.jdbc.encode[0].sql=SELECT * FROM public.vt_user WHERE email=?
cas.authn.jdbc.encode[0].driverClass=org.postgresql.Driver
cas.authn.jdbc.encode[0].url=jdbc:postgresql://localhost:5432/tracking
cas.authn.jdbc.encode[0].user=postgres
cas.authn.jdbc.encode[0].password=postgres
cas.authn.jdbc.encode[0].saltFieldName=salt
cas.authn.jdbc.encode[0].passwordFieldName=password
cas.authn.jdbc.encode[0].healthQuery=SELECT 1 FROM INFORMATION_SCHEMA.TABLES
cas.authn.jdbc.encode[0].numberOfIterations=1
cas.authn.jdbc.encode[0].numberOfIterationsFieldName=
cas.authn.jdbc.encode[0].staticSalt=
cas.authn.jdbc.encode[0].algorithmName=SHA-1
cas.authn.jdbc.encode[0].dialect=org.hibernate.dialect.PostgreSQLDialect
cas.authn.jdbc.encode[0].passwordEncoder.type=DEFAULT
cas.authn.jdbc.encode[0].passwordEncoder.characterEncoding=UTF-8
cas.authn.jdbc.encode[0].passwordEncoder.encodingAlgorithm=SHA-1
The database I am connecting with is a PostgreSQL DB. The passwords were previously encoded using Spring Security's 3.2.5 ShaPasswordEncoder with the default strength which is SHA-1 plus a salt value. I have tested the CAS DB Authentication configuration by entering valid credentials in the CAS Server's default login page, but authentication always fail and return "Invalid credentials." Additionally, I am already aware that the 3.2.5 ShaPasswordEncoder is deprecated, but I am not planning to change it's implementation. The logs show that the username can be successfully queried from the user table, but the passwords from the table and the input don't match.
Right now I am looking for any approach on resolving this issue. I am still relatively new to CAS, and I really appreciate the much needed help. Thanks!
I resolved this issue by modifying the QueryAndEncodeDatabaseAuthenticationHandler.java file from the cas-server-upport-jdbc dependency (of the same CAS version) to use Spring Security's ShaPasswordEncoder instead of the one used by CAS which is Apache Shiro's default hash service.
Specifically, what I did was to add the modified java file (plus the AbstractJdbcUsernamePasswordAuthenticationHandler.java) inside the CAS maven overlay that I'm using inside the src/main/java/org/apereo/cas/adaptors/jdbc directory. The relevant function that I modified inside the java file is named digestEncodedPassword. I commented out the original lines of code and replaced it with my implementation of the ShaPasswordEncoder. The custom source code should be compiled alongside when building CAS.
We're using Jasypt to encrypt some config properties (database passwords) but since the decryption key is stored on each environment's file system we have to do some manual #Bean configuration to load the password from the file then overlay loading properties with an EncryptablePropertiesPropertySource.
Because it is so manual we've had to run this code in #PostConstruct of the WebApplicationConfig class and (although this hasn't happened yet) it runs the risk of loading these after the datasource bean is configured with calls to the Environment - giving null pointer exception. #Lazy loading would be an option but obviously this means we'd then be working with fragile config which we'd like to avoid.
Ultimately we want to be able to use the default classpath:application.properties so don't want to affect existing (default) setup, but we do want to be able to use an encryptable property source as a complete replacement to the Spring one, and to have Spring load the decryption code from a file before anything else happens. Is there a way to tighter integrate loading encryptable properties earlier in the application startup and configuration?
I'm "tailoring down" my previous answer since it got deleted because it was duplicate from a different question:
This library does exactly what you need jasypt-spring-boot which is basically to allow you use the #PropertySource annotation to define your properties the same way you're use to. You just have to add an extra annotation (#EnableEncryptableProperties) to your configuration file.
It is not only limited to that, every PropertySource present in Environment will be converted to EncryptablePropertySourceWrapper, a custom wrapper that checks when a property is encrypted and decrypts it on access.
The link Dave provided in the comments section unfortunately points to nothing now, but navigating from its root I got to the following example project:
https://github.com/spring-cloud-samples/configserver (also written mostly by Dave, of course)
I think it serves as a great example for what was discussed in the comments until now.
Also, for future reference (maybe it will be done at some point), there's a Spring Framework Jira ticket for the feature of using encrypted properties: https://jira.spring.io/browse/SPR-12420