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.
Related
I need to develop a web application for the Intranet users. I don't want them to enter the login credentials each time they visit the site. It should be automatically loaded from the System Username and Password.
I have successfully implemented functionality which prompt user name and password registered with active directory and validate against LDAP. I need some tips to login directly from intranet website without prompt username & password.
Here is my queries, please let me know your suggestion.
Is it compulsory to set SPN?
Do we need to create separate keytab file for each client? In my organization, there is around 800 people are working so should I need to add all client principal in keytab file & copy to client machine to perform autologin.
I have tried many API's like JESSO, Waffle, Spring Kerberos, SPNGO but failed to implement auto login.
If you want to use Kerberos/SPNEGO (which would be my recommendation) you do have to set up SPN. And you only need one keytab for AD domain. Are you running your Java program on some app server, like Weblogic, or as a standalone program? Servers do have security framework that you could use, while for standalone program you'd have to do a bunch of stuff manually.
I've found that the easiest way to do this is to use Atlassian's Crowd (https://www.atlassian.com/software/crowd/overview) instead of implementing it yourself. It's a commercial product, but last time I checked, it was dirt cheap, and it just works.
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 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.
Currently I take part in developing a system based on Java EE (WebLogic server, to be more precise) and I am wondering how to protect some private data from administrators. For example, some parts of a system stores credentials for legacy systems in a deployment descriptors as plain text and this is bad because a deployer can read application configuration file (ejb-jar.xml, for example) and steal username and password for powerfull account. I want to close this security hole, but don't know how.
Now I am interested in protecting this kind of data:
Login
Password
Private key for symmetric encryption
From here I've discovered that I can use a JCEKS keystore to protect this type of information, but I can not understand how to use it. My application still should contain the kestore password and the key password to access it. So, a depoyer can steal passwords for keystores and keys, find my secure storage and steal credetials. Obviously, I can revoke read privileges from the deployer account, but then he can decompile my appliaction and develop his own similar app (or edit my one), that simply prints secure data to some file or send it by email... And now I am stuck...
Can anybody give me some links that can explain how to protect a system from administrators? Weblogic related links will be preferable. I totally understand that it is not possible to protect from all administrators and there should be some security administrator that will be responsible for keystore management and so forth, but I want to secure all sensitive data from everybody else.
RESULTS
Both jtahlborn's and slim's answers are correct, but slims's answer in more interesting. I think that in my case it will be appropriate to accept only signed applications for installation on the server. This decidion can solve problem with applicatoin modifications done by a administrator. Administrators will have password from keystore and all keys, but they will not have access to keystore file at all. Access to keystore file will have only special security administrators ('rw') and server ('r'). So, everybody will have the key, but nobody (except security administrators) will have access to the box.
There is no solution to this problem unless you enter login credentials at application startup (assuming the admin cannot access the application memory, which may not be a safe assumption). any solution which involves the keys sitting in the same place as the application will result in an administrator (with application filesystem access) being able to access any sensitive data accessible by the application. this is similar to the DRM problem (you can't give someone a locked box and the keys and expect that they can't open the box).
I think the meat of this question is in the definition of "admin".
You've said that you're comfortable with a "security admin" who does have access to key stores.
Traditionally, UNIX types think of "admin" as being the "root" user - someone with access to everything on the machine. Root can do literally anything, right down to peeking and poking at application memory, or reading/writing to raw disk addresses. If the server can get a private key, so can root.
If you want to define an "admin" role with more limited access, then yes, you could set up something where such users existed. They would need to have fewer privileges than the server application itself, since there is at least one thing the app can do (get a private key) that the "admin" cannot.
Such a user probably wouldn't be able to install the app either (since, if they could, they could create and install a version of the app which exposes the private key). Your "admin" couldn't therefore deploy the component that works with the private key. They could, however, potentially deploy a module that runs within that container (as long as the container cannot supply the private key to the module).
However, it's not just the key you want to protect. The real "secret" is the data encrypted using the key. So we still have a problem with the approach above. If the module can read the encrypted data, then so can an "admin" with the same privileges as the module. And that includes anyone who can install the module.
You could investigate ways to sign the module, so that an "admin" could not create their own version.
There comes a point, though, where the measures required to enable untrustworthy admins, become more expensive (in terms of time and effort) than simply using trustworthy admins.
So, you need to make a list of things your so called "admin" can do. Depending on what those things are, it may well be possible to allow a non-root user to do those things. On UNIX, you might use a tool like sudo to allow a non-root user to do things like start/stop the server, read logs, clean logs, etc.
It might be possible to separate the authentication from the rest of the application.
For example, if you communicate with the legacy systems via a TLS-secured socket, you could write a small separate application that accepts unencrypted connections from the application, then makes a secure, authenticated, connection to the legacy system, and pumps data between the application and the legacy system. Essentially, it's an authenticating proxy. Then, the application wouldn't need these keys. You could install and operate the application as a user who didn't have permission to read the files containing the key, but the application could still communicate with the legacy systems.
Of course, now you have the problem of how to authenticate the application to the proxy. You might feel that the machine is secure enough that you don't need to do that at all - as long as the proxy only listens on the loopback interface. If not, if you could use a unix domain socket instead, then you could control access using filesystem permissions: you could run the application as some user in some particular group, then restrict access to the socket to members of that group. Java doesn't have unix domain socket support in the standard library, but you can add it with junixsocket or JUDS.
I'm using Jaspyt and Spring 3 in my Java project. I currently store the database connection properties in a properties file. The user name and password are plain text, so I've been looking at using Jaspyt's EncryptablePropertyPlaceholderConfigurer.
The documentation and tutorials suggest storing the master password used for decryption in an environment variable. Is that really any more secure than storing plain text values in the properties file? If someone compromises the box, wouldn't the master password be either visible in (1) the environment variables or (2) the server start-up script? I suppose you could manually set the environment variable and unset it after server start-up, but the manual process of that seems unmanageable.
Am I just being paranoid? Is there an approach that you've used to secure your connection user names and passwords?
Storeing clear text passwords is never a safe procedure. An attacker who takes over the server has access to your passwords in all cases.
If manual entry is not an option (as usual) you can only hide the password only for a part of your team. If you not want to disclose the database passwords, use a JNDI database connection. This makes the passwords only visible to the application server administrators.