Jasypt: how secure master password? - java

Colleagues, i used Jasypt in my spring-boot project (standalone jar running on Windows).
I need to pass master password via command line to run jar .
It looks like:
java -jar -Djasypt.encryptor.password=masterpass app-1.0.0-RELEASE.jar
So anybody can see masterpass via Windows Task Manager:
How to secure this masterpass?
I have found an example where master password is stored in Windows Environment variable, but, it seems, no good idea.

It is generally very difficult to hide anything when running on the client's workstation. At the end - when passwords/keys are encrypted, you need to store the password or private key somewhere anyway :/
You can encode/encrypt data to make it more difficult, but once the binaries and configuration reside at the client side, you won't stop a dedicated adversary easily.
If you at least don't want to show the password outside (in the environment or command line) - how about reading the master password from a file and setting a system property in the main before running anything else?
(please let me know if it worked)

At least you should not provide the master-password via commandline option as if other users have access to the machine they can retrieve it from the process list.
Instead provide it via a separate configuration file. So in case you are using spring-boot and have your regular env properties in config/application.properties then simply add a config/application.yml file with just the master-password and keep that only on the machine with only user permissions (chmod go -rxw). See e.g. here:
https://github.com/oasp/oasp4j/wiki/guide-configuration#password-encryption
Everything else from the installation may come from your git repo where people with access only see encrypted passwords but can not decrypt unless they have the master-password what they do not have if they have no physical access to the productive machine. Operators may provide the passwords only encrypted to the dev team so they never know the actual passwords. DevOps gurus might not like this but keeping the passwords secret to a minimum number of admins is generally good for security.

Related

Hide or encrypt credentials for JMeter completely?

can I have some ideas on security in JMeter please?
in order to use JMeter behind a corporate proxy the following format can be used to launch from the command line:
jmeter -H localhost -P 8888 -u username -a password -N localhost
Once JMeter is opened (and usual https certificate process followed) I use JMeter recorder to access a corporate application and complete usual business processes (including entering login details).
There are at least two issues with this approach:
a) network scans record any java application being run, with credentials in plain text
b) the JMX file produced has credentials saved in plain text, from when user logs into any secure application.
For the first issue, is it possible to change the http.proxyPass and http.proxyUser values? If so, how best to secure them to prevent anyone monitoring the network from seeing them?
For second issue, how best to hide this information? Parameterize the relevant http requests after manually checking the entire project? The most secure way would be to avoid using the recorder but this would be impractical.
Thanks, D
Any data will be stored in the .jmx test script as plain text.
If you don't want it to appear there you can:
Add User Defined Variables and define the JMeter Variables reference names with their respective values which you want to substitute there
During recording HTTP(S) Test Script Recorder will automatically substitute the values with the JMeter Variables
Replace hard-coded sensitive values with __P() functions
When you will be executing JMeter test you will be able to provide values in the runtime via -J command-line arguments as:
jmeter -Jusername=secret-username -Jpassword=secret-password etc.

How to securely apply truststore and keystore password to JConsole configuration

I am using JConsole to securely connect to a remote JMX endpoint on another machine.
I am doing my best to use TLS every step of the process, and this includes having the hosts authenticate each other. I have done this by importing each's certificate into the other's truststore
I have gotten all of this to work correctly, with jconsole now being launched with:
jconsole -J-Djavax.net.ssl.keyStore=/path/to/keystore -J-Djavax.net.ssl.trustStore=/path/to/trustStore -J-Djavax.net.ssl.keyStorePassword=password -J-Djavax.net.ssl.trustStorePassword=password
However, I do not like this solution as I am now supplying passwords on the commandline, making it readily readable by anyone with access to the host or our monitoring tools.
I fixed this issue with the accompanying java application by specifying the location of ssl config file, where the passwords and paths to keystores are kept:
java -Dcom.sun.management.jmxremote.ssl.config.file=/path/to/ssl_config ...
However, this does not work with jconsole. I have not even received any indication that the config file is even being referenced or read. I have tried numerous ways to reference a config file, and tried to get jconsole to read the passwords from a file, but none will work.
Does anyone know of a way to supply passwords to jconsole without supplying them in plaintext on the command line?
You can pass -Dcom.sun.management.jmxremote.password.file=PASSFILE where PASSFILE is the file name and contains the user name/password pair, space separated.
See https://gquintana.github.io/2016/09/01/Securing-remote-JMX.html

Passing password to ssh(Server) at runtime through web application

when I run kinit ganesh#abc.com it asks for the password when I run through the terminal. I am trying to build same as web application using java
Acceptance criteria:-
password should pass through UI and we should able connect to the server. i.e password which we pass through UI should assign asa password.
I would recommend you to use Jsch, you can find this library here
http://www.jcraft.com/jsch
And an example or ssh connection here
http://www.jcraft.com/jsch/examples/Shell.java.html
If you're using OpenSSH ssh client, you can try implementing passing password via a companion program, specified via SSH_ASKPASS variable. Basically, you need SSH_ASKPASS to point to a binary ssh would run, and that binary must output the password on stdout.
Check this answer: How to make ssh receive the password from stdin for more details and a concrete example.
The downside is, you need an external binary - and you need to think about its security. For example, if the binary is a dynamically-generated shell script in /tmp - you need strict filesystem permissions so no one but your ssh child process can read or execute it. And if the binary itself is static and takes password from, for example, an environment variable, you must make sure that SSH won't accidentally pass this variable to remote host (e.g. via accidentally specified SendEnv).
You can use some Java SSH library (like suggested Jsch - there is a list here: SSH library for Java), if that fits your requirements. It should be the most flexible option - in terms of control you have over SSH client behavior, unless you want something Jsch doesn't support.
Also, I'd strongly suggest to consider not using passwords, but your server having a private key, and servers you connect to appending its public key to ~/.ssh/authorized_keys (unless you need password-based logins for exactly this purpose, of course). If that's a feasible scenario, you can avoid sharing any sensitive information entirely, significantly improving the security.

How to secure password for SQL Server login from a java form application

I am making a Java based form desktop app, a mini login form, that will be able to login into a grand system which is online in asp.net.
The purpose of this app is to install on pcs, and whereever this exe is installed, the website could be logged in, other wise not.
The problem is, i have put the connection string of sql server in it, and employees will install this app on their machines, there is a tool available which decompile JAR and classes. And when i checked my classes in it, it was showing my sql server password. And it can give a chance to them to hack this app, this is really dangerous for us to provide them or give them a chance to get sql server password.
Can you please help, is there any such solution that i could give MD5 encrypted password or some encrypted password in connection string and sql server could be able to understand it.
Thanks
There are a few ways you can handle this.
the user info in your connection string should be limited to execute exactly one procedure: the one that tests if the MAC address is valid. This limits exposure. Not in an ideal way, but it's something.
Don't send a connection string at all. Instead have the java application post the mac address to a web service. The service should connect to the database server to determine authorization. Better than option 1.
Even better: Don't rely on MAC addresses. If you are worried that someone will look at the connection string then it stands to reason they might change their MAC address to mimic another machine. It stands to reason that anyone familiar enough to directly connect to a database server will also be familiar enough to download one of the many freely available tools to spoof their MAC.
Which leads to a comment: I think your doing this wrong. If the entire purpose of the java app is to simply read the MAC to validate whether that particular machine should have access then you have some serious issues with understanding security and I think you really need to evaluate what, exactly, it is you are trying to stop.
You can use integrated authentication, provided that the database server is in the same active directory domain as your users. Simply specify Integrated Security=SSPI in your connection string and grant regular users rights corresponding to what you want them to be able to do in the database (for example, read only access), but no more.

Using TGT acquired in Java for SSH/Other applications

Currently, I am able to authenticate users in a java application by using JAAS and grabbing the ticket-granting-ticket that is sent from a Windows server running Active Directory. This is easily done with the Krb5LoginModule in java.
Now I would like to run an ssh command from my java application and use my TGT to enable ssh not to ask for password. I have seen some tutorials (OpenSSH & Kerberos) for getting ssh to work with kerberos, but they use kinit to get their TGT and the ticket is stored in /tmp/krbcc_XXX. Then after the ticket is generated they can ssh freely.
I could write the TGT to disk and store it in /tmp/krbcc_XXX or I could run the ssh command in a PrivilegedAction, however I don't know if either will work. Is there an accepted way to do this?
Basically, I would like to call something like this and have it not ask me for a password:
// Create Command.
List<String> arguments = new ArrayList<String>();
arguments.addAll(Arrays.asList("ssh", "user#host", "xterm"));
// Run SSH command.
ProcessBuilder process = new ProcessBuilder(arguments).start();
You have to clarify first who will initiate the SSH request. Java or the underlying Linux/Unix system. If you go with the latter, this is not cross-platform and not the Java way. You should use a Java SSH impl which supports Keberos. Everything should go smooth. JSch is a pure Java impl with gss-api-with-mic support.
On the other hand, you could try to get the private credentials from the Subject created with the LoginContext and write it to the default CC file location.. After you have done that, try klist. If it reads the cc file, you're done. If this does not work, you could examine Sun's CC reader code and reverse it. Probably, the sun.security.krb5.internal.ccache.FileCredentialsCache is the interesting one along with its update and save methods. The task is to have the private subject credentials be compatible with the desired class sun.security.krb5.internal.ccache.Credentials.
Note: This solution is completely Sun-dependent. I would go for the first approach or you rather run kinit first.

Categories

Resources