I have to create a java application wich makes a connection to a DB.
Everything is easy until this point. But I need to include a configuration option with the porpouse of allow the end user enter their own parameters (server host, user, pass, database, port, etc.) in order to connect to the DB. Another easy task. Now every time the user starts the application I need to read these presets given by the end user, in other way remember the user's connection preferences.
I found an easy way to do this using the Properties library in the Java's API. But I have a security issue. The user's preferences are exposed to be access easily (username and password mainly).
Is there a way to save this parameters encrypted?
I need a good and simpliest solution for this security issue.
I doubt it. In FileZilla Client 3.6.0.2, I found my login data easily without encrypted. If it was possible to save this parameters encrypted, FileZilla would do it.
Related
This is a follow up to:
Using JSch to SFTP when one must also switch user
This issue has been on the back burner since I asked the original question while our server management team reviews their policies, but I am now picking it up again!
What I want to do is to use JSch to connect to a remote server and then use sftp or scp to access some files - as per the code example in the original question. The issue is that these files are owned by another user and so I need to su to that user and then provide a password before issuing the sftp or scp command.
This cannot be done in JSch and this is right because it is a security risk to be able to send the password through the exec channel. So these are options I have going forward as I see them.
Override JSch functionality. Martin has very helpfully provided some guidance in an answer to the original question as to how this could be done by and how the password may be passed in "through the back door". But I am not confident in my own ability to override the JSch code and once again, even if successful, I would be circumventing a security feature that is there for legitimate reasons, so I am reluctant to attempt this.
On the server, grant my user password-less access to the other user. This is a no as my server management team will not agree to this.
Have a server-side .sh script that can be run by my user to gain access to the files. Again, this is a no as my server management team will not agree to it!
Automate a putty session i.e. phsically open putty and pass commands to the putty session line by line from the Java client.
Give up! Should I accept that I am trying to do something here that should not be automated and simply have a manual test instead?
I would be extremely grateful for any thoughts/guidance.
I am trying to do something here that should not be automated.
That's correct in principle.
The only correct automatic solution is to directly login with the user that has access to the files. Everything else is just a hack or working around your security policy. Ideally you should authenticate with a dedicated private key to allow monitoring the access from your application and to be able to control the access (e.g. temporary turning it off, without affecting other uses of the same account).
Though I can imagine that your system administrators won't allow you the direct login, because they cannot foresee what (if any) security issues it brings.
I just wanted to share that I have got a solution working for this question by adapting the sample JSch example, JumpHosts.
http://www.jcraft.com/jsch/examples/JumpHosts.java
Overriding the inherited methods in the static class MyUserInfo allowed me to automatically accept prompt boxes, input boxes, etc without physically having to use the keyboard, so I have a fully automated test as desired.
It's great that the jcraft team provide such useful worked examples. Thanks for everyone who took the time to read and consider my question.
Edit: As per Martin's comment, I should point out that this only works if you have a special rule in SSH configuration that allows direct user2 login from localhost (while not allowing direct remote login). That's not sudo. So this cannot work in general.
I'm developing an Android app which has a service to upload images/files to a FTP server.
To make that possible, the app on the device has to log in into the FTP server before sending data.
And here comes my problem. The user does not need to / have to know about the FTP login data. Only the app itself. I have to store the login data in the Java class. But how should I secure the user and password?
I could encrypt it or obfuscate it. But I think it would be possible for a hacker to read the password at the runtime when the "setPassword(passwordString) methods is called by the JVM:
String passwordString = "myPass";
JSch ssh = new JSch();
session = ssh.getSession(SFTP_USER, HOST_ADDRESS, 22);
session.setPassword(passwordString);
So how could I store my credentials inside the APK file and secure them? I don't want anyone to get access to my FTP server.
how could I store my credentials inside the APK file and secure them? I don't want anyone to get access to my FTP server.
The stated problem cannot be solved.
It does not matter how clever your obfuscation technique is. If you hide fixed credentials in the APK file then someone who analyses your app is going to find them.
If you take only one thing from this answer, let it be that having a single, static password for your server is extremely problematic, as you'll never be able to change the password server-side, because you'd break all the apps. It will be a matter of time before your password is public knowledge and there will be nothing you can do about it.
Any reasonable approach requires separate access credentials for every individual user.
A traditional user sign-up system that involves a confirmation email is a pretty good approach. You can use something like Google+ sign-in or Facebook Connect to minimize the hassle for the end user.
If you absolutely insist on having zero user interaction, an approach that might work (somewhat) is to have the app register for Google Cloud Messaging and then send it a push notification containing access credentials, which the app will store in the KeyChain.
If you generate a unique user ID and password for every app installation, you'll be able to monitor the server and block any abusive access credentials without affecting any of the other users. If you somehow factor the code signing identity of the APK file into the process, you'll have a basic defense against people repackaging your app. This approach will not protect you against an intelligent attacker, but it might raise the bar high enough for your purposes.
Also, regardless what you do, be sure to properly verify your server's SSL certificate. If you don't, an attacker will simply run your connection through a proxy server.
I'm part of a Java Spring Web app which should be very secure. So far, on test environment we're loading database username & password from a property file which lies on classpath. The password is encrypted with a key which we load from local file system.
My job is to find a better way(more secure one) using software tools only. I was thinking about supplying the db username and password on startup of webapp or smth like that(But still does not seem ok because the DB admin should be present on startup). Other than that I'm stuck.
What is the best way to deal with this issue?
You need to lock down the database so that only the app can talk to it with minimal creds as possible.
One way is restrict it so that only app servers private IP is only accepted. Make it so the database only listens to private (internal) network connections.
The password is a red herring.
I'm in the process of writing a server application that mainly allows people to submit jobs to a DRM system (e.g. TORQUE) over RMI. The application needs to run as root so that it can submit proxy jobs (where a job is run as a user other than the user who submits it), however this obviously isn't secure - the user name is simply a string parameter in the RMI. Anyone could pass any user name in and have a job run as that user.
What's the best way to get Java to authenticate this user name against authorised users of the system (with the aid of a password that would also be passed in)? I've had a look at JAAS and Apache Shiro, but they seem to be all about creating your own authentication methods. I want to use the system's existing authentication methods (Unix-like system), whatever they happen to be. Essentially if the user can SSH in, they're all right.
If your backend uses LDAP (which is possible if you have to manage a relatively large number of users for which a local /etc/passwd might be tedious), you can use JAAS and the existing LdapLoginModule.
If you want to authenticate against you local system (assuming Linux server) without this, it looks like JAAS-PAM might be able to help, although I've never tried it.
I'm writing on a Java EE project which will have everything from 3-6 different clients. The project is open source, and I wonder what security mechanisms one could/should use. The problem is: Because it is open source, I would believe that it is possible for anyone with a user to write their own client (maybe not realistic, but truly possible) and make contact with the server/database. I've tried to go through all the scenarios of reading/writing different data to the database as different roles, and I conclude with that I have to have some security mechanism on a higher level than that (it is not enough to check if that account type is allowed to persist that entity with that ID and so on...). In some way I have to know that the client making contact is the correct client I wrote. Could signing the Jar files solve this entire problem, or is there other ways to do it?
-Yngve
I really think that if restricting the available activities on the server side (based on role) is not sufficient, than you've got a bigger problem. Even if a user doesn't write their own client, whatever mechanism you are using for your remote calls is likely to be vulnerable to being intercepted and manipulated. The bottom line is that you should limit the possible calls that can be made against the server, and should treat each call to the server as potentially malicious.
Can you think of an example scenario in which there's a server action that a particular authenticated user would be allowed to take that would be fine if they're using your client but dangerous if they're not using your client? If so I'd argue that you're relying too strongly on your client.
However, rather than just criticize I'd like to try to also offer some actual answers to your question as well. I don't think signing your jar file will be sufficient if you're imagining a malicious user; in general, public-key cryptography may not help you much since the hypothetical malicious user who is reverse-engineering your source will have access to your public key and so can spoof whatever authentication you build in.
Ultimately there has to be someone in the system you trust, and so you have to figure out who that is and base your security around them. For example, let's imagine that there may be many users at a particular company who you don't necessarily trust, and one admin who oversees them, who you do trust. In that scenario you could set up your client so that the admin has to enter a special code at startup, and have that code be kept in memory and passed along with any request. This way, even if the user reverse-engineers your code they won't have the admin code. Of course, the calls from your client to your server will still be vulnerable to being intercepted and manipulated (not to mention that this requirement would be a royal pain in the neck to your users).
Bottom line: if your user's machine is calling your server, than your user is calling your server. Don't trust your user. Limit what they can do, no matter what client they're using.
Well the source may be available for anyone, but the configuration of the deployment and the database certainly isn't. When you deploy the application you can add users with roles. The easiest thing to do is to persist them in a database. Of course the contents of the table will only be accessible to the database administrator. The database administrator will configure the application so that it can access the required tables. When a user tries to log in, he/she must supply a username and password. The application will read the table to authenticate/authorize the user.
This type of security is the most common one. To be really secure you must pass the credentials over a secure path (HTTPS). For a greater degree of security you can use HTTPS client authentication. You do this by generating a public key for every client and signing this with the private key of the server. Then the client needs to send this signed key with every request.
EDIT: A user being able to write his/her own client doesn't make the application less secure. He/she will still not be able to access the application, if it is required to log in first. If the log in is successful, then a session (cookie) will be created and it would be passed with every request. Have a look at Spring security. It does have a rather steep learning curve, but if you do it once, then you can add security in any application at a number of minutes.