We Keep Coding

Storing configurable encrypted password of MongoDB User in Spring Boot

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

how to pass password to a java (Spring boot) application

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

How to avoid hard coded database credentials in code

I've been searching for a way to avoid hard coding my database credentials into my code base (mainly written in Java), but I haven't found many solutions. I read this post where they said a one way hash could be the answer. Is there another way of securely connecting to a database without running into the risk of someone decompiling your code?
Just to clarify, I'm not looking for code, rather a nudge in the right direction.

If you can used spring boot application, then you can configure using cloud config method. I have added some postgresql db connection details for your further reference. Please refer following link for spring boot cloud config. spring_cloud
spring.datasource.driverClassName=org.postgresql.Driver
spring.datasource.url=jdbc:postgresql://{{db_url}}:5432/{{db_name}}
spring.datasource.username=postgres
spring.datasource.password=
spring.datasource.maxActive=3
spring.datasource.maxIdle=3
spring.datasource.minIdle=2
spring.datasource.initialSize=2
spring.datasource.removeAbandoned=true
spring.datasource.tomcat.max-wait=10000
spring.datasource.tomcat.max-active=3
spring.datasource.tomcat.test-on-borrow=true

You could load a config file in your code. Define some kind of file, such as JSON or XML, and define all of your configurations in there. You could point to the file as a command line argument, or just hardcode the file path.
Here's a post talking about parsing JSON config in Java:
How to read json file into java with simple JSON library

You can refer to these post. They are basically just saying to either hash, store it in a property file or use an API. Some of the posts are not merely on Java but you can get ideas from them.
How can I avoid hardcoding the database connection password?
https://security.stackexchange.com/questions/36076/how-to-avoid-scripts-with-hardcoded-password
https://www.codeproject.com/Articles/1087423/Simplest-Way-to-Avoid-Hardcoding-of-the-Confidenti

The solution in our team, database as a service,other application use it's API to get database credentials,the request contains simple credentials like application name.

You have several options to avoid hard code values in your source code:
Properties using Advanced Platforms
Properties from Environment variables
Properties from SCM
Properties from File System
More details here:
https://stackoverflow.com/a/51268633/3957754

Custom User Store Manager not recognized (WSOIS 5.3)

I've written a custom User Store Manager to interface WSO2 to a database managed by ASP.Net's Simple Membership Provider. My main issue is that SMP uses PBKDF2 for password hashing and the standard JDBC User Store doesn't seem to support that.
I basically used https://docs.wso2.com/display/IS530/Writing+a+Custom+User+Store+Manager as a template, as the example implements a different password hashing algo, which is exactly my use case.
You can find my POC implementation here: github project wso2_custom_userstore I built a jar, put it into the dropins directory and restarted the server. The server complained about lack of bundle headers, but that's it. When adding a new user store there's only the standard stores, nothing more. I then configured a JDBC user store and changed the class to the one I wrote. The only effect I saw was that my previously configured User Store had vanished. I tried putting the .jar into the libs directory instead, didn't change anything.
As that didn't seem to work and the server complained about missing bundle headers I built a OSGI bundle that exported my CustomUserStoreManager Package (the source can be found on github as well, I'm not allowed to add more than two URLs) - now the bundle gets loaded and activated but nothing more. Still my class is nowhere to be seen. I don't see it as an available class in the User Store add dialog and I don't see it as an available class in the log config. No hint of it anywhere, not in the log files, not in the server's startup output. Nada.
Am I doing something wrong?
I have to add that I by no means am a Java developer nor a developer at all. I'm evaluating WSO2 for a customer and this is supposed to be a PoC. Once it works and I know that using PBKDF2 hashes are possible someone more competent is going to build a production version.
Thanks in advance,
SunTsu

WSO2 IS 5.3.0 is based on org.wso2.carbon.user.core 4.4.11 [1] and you are using 4.2.0. Documentation should be updated in this case. You can find a sample code [2] which is written for WSO2 IS 5.1.0 and article in [3].

Environment configuration management?

There is a team develops enterprise application with web interface: java, tomcat, struts, mysql, REST and LDAP calls to external services and so on.
All configuration is stored in context.xml --tomcat specific file that contains variables available via servlet context and object available via JNDI resources.
Developers have no access to production and QA platforms (as it should be) so context.xml is managed by support/sysadmin team.
Each release has config-notes.txt with instructions like:
please add "userLimit" variable to context.xml with value "123", rename "DB" resource to "fooDB" and add new database connection to our new server (you should know url and credentials) named "barDb"
That is not good.
Here is my idea how to solve it.
Each release has special config file with required variable names, descriptions and default values (if any): even web.xml could be used.
Here is pseudo example:
foo=bar
userLimit=123
barDb=SET_MANUAL(connection to our new server)
And there is a special tool that support team runs against deployment artifact.
Look at it (text after ">" is typed by support guy):
Config for version 123 of artifact "mySever".
Enter your config file location> /opt/tomcat/context/myServer.xml
+"foo" value "bar" -- already exists and would not be changed
+"userLimit" value "123" -- adding new
+"barDb"(connection to our new server) please type> jdbc:mysql:host/db
Saving your file as /opt/tomcat/context/myServer.xml
Your environment is not configured to run myServer-123.
That will give us ability to deploy application on any environment and update configuration if needed.
Do you like my idea? What do you use for environment configuration management? Does there is ready-to-use tools for that?

There are plenty of different strategies. All of them are good and depends on what suit you best.
Build a single artifact and deploy configs to a separate location. The artifact could have placeholder variables and, on deployment, the config could be read in. Have a look at Springs property placeholder. It works fantastically for webapps that use Spring and doesn't involve getting ops involved.
Have an externalised property config that lives outside of the webapp. Keep the location constant and always read from the property config. Update the config at any stage and a restart will be up the new values.
If you are modifying the environment (i.e. application server being used or user/group permissions) look at using the above methods with puppet or chef. Also have a look at managing your config files with these tools.
As for the whole should devs be given access to prod, it really depends on a per company basis. For smaller companies where the dev is called every time there is a problem, regardless of whether that problem is server or application related, then obviously devs require access to the box.
DevOps is not about giving devs access to the box, its about giving devs the ability to use infrastructure as a service, the ability to spawn new instances with application X with config Y and to push their applications into environments without ops. In a large company like ours, what it allows is the ability for devs to manage the application they put on a server. Operations shouldn't care what version is on their, thats our job, their job is all about keeping the server up and running.

I strongly disagree with your remark that devs shouldn't have access to prod or staging environments. It's this kind of attitude that leads to teams working against each other instead of with eath other.
But to answer your question: you are thinking about what is typically called continuous integration ( http://en.wikipedia.org/wiki/Continuous_integration ) and moving towards devops. Ideally you should aim for the magic "1 click automated deployment". The guys from Flickr wrote a lot of blogs (and books) about how they achieved that.
Anyhow .. there's a lot of tools around that sector. You may want to have a look a things like Hudson/Jenkins or Puppet/Chef.