I'm building a web application that has up until now collected and stored data only of low sensitivity, in the next few months the web application will need to begin collecting more sensitive data and so I have determined that I need to ensure that the data is encrypted when stored in the database so that it cannot be accessed even if the database is compromised.
I have read the OWASP Cryptographic Cheat Sheet, most of which makes a lot of sense, however there is one point I can't get my head around.
Rule - Store unencrypted keys away from the encrypted data If the keys
are stored with the data then any compromise of the data will easily
compromise the keys as well. Unencrypted keys should never reside on
the same machine or cluster as the data.
Possible solutions:
Store the key un-encrypted as root, load the key into the application which runs as a less privileged user at startup via an environment variable, so the key is only ever stored as the root user. --- This doesn't satisfy the OWASP rule as the key is still located on the server.
Encrypt the key on the filesystem, and require a second key, such as a password to decrypt that at startup that is entered by a human user. --- While this satisfies the OWASP rule, its impractical to require a human user to be on hand as the application starts up.
Is there a recommended or recognised solution to this problem?
While the problem is technology agnostic, technology specific solutions are welcome, i'm presently using:
Java
Spring
Hibernate
MySQL
Centos
Related
I've configured servlet, and other things needed to have role-based access to resources. I'm using JDBCLoginService to access roles data from DB. All works great, my only problem is: how to configure Jetty that in database I'll have passwords encrypted (preferably not MD5).
I found several docs saying you can run some tool given by jetty and it produces you MD5 or OBF, etc. But I wonder how to get list of avail ciphers?
I believe in table with users, column with password should have something like "MD5:897897979".
But I want to add users to this table by functionality like register/signup. So I need to encrypt password sent from browser and put to DB. But I can't control algorithm which is used by JDBCLoginService to check data sent by user from login page.
I believe it's implemented in some smart way that not much extra code is needed, but I can't just find info how to do it :/
I had a similar problem and tried to resort to the facilities provided by the Password class in the Jetty distribution.
However, eventually I couldn't adopt that approach since I was in need of storing the passwords hashed with a specific algorithm (namely sha256 or sha512) and I couldn't find a way to get the JDBCLoginService work with such hash algorithms.
This was kind of a let down, especially because Tomcat comes with the support of those algorithms out of the box when it comes to handle database-backed authentication scenarios.
I found this problem today. And the solution I ended doing is to have the sha256 calculated for the password input field in the browser side. You can do it on form submit or any other event if you are careful not to re-hash. Simple check or password length less that 64 would be sufficient to avoid rehash. I used the below to do the hash
https://developer.mozilla.org/en-US/docs/Web/API/SubtleCrypto/digest
Paradoxically this solution makes it stronger as the password is hashed from the browser itself. Of course it could be exploited from this same web app but not in others that do not use hashing from browser if the is is used for other authentications.
One of my java class will connect to a another server and do some operation using rest services. Java class requires - username and password to connect to remote server. On other machines we used to store the credentials using oracle cwallet.sso but this is not an option for current machine. I am thinking to store the encrypted password in properties file adding some salt. I also need to store the key and salt string to some secure place. do we have any alternative in RHEL for password management like cwallet or any suggestions what to should be the best way to achieve this?
Please note that I will invoke this class using shell script.
Thanks
This is tricky, because if someone gets access to your server is already game over. So the solution is not just to encrypt the data, as it won't do much, but you need security in depth.
To put this in context, you can have the password encrypted, salted whatever... When an attacker gets access to the server, he won't be able to read any of those files (even with the encrypted password) unless he is able to become the user running the app. If he manages to do that, he only needs to do a memory dump and then fish for passwords (which is not hard).
So a real world solution is:
Only allow a restricted number of people to log on the server.
Only allow an even smaller number to become the user which runs the application server.
This group of people are the ones who can read/update the properties file
Disable any kind of backups on the files that contain secrets.
Again, encrypting passwords on the files might give you a sense of security, but again, if you follow the steps above, anyone who can read the file, will also be able to read the memory contents of the app. And even if someone does things right and stores that password in an bit of offheap memory, some linux tools can read the whole memory map of a process, so again, game over.
Using encryption in this case just adds obscurity and no real protection.
I have a flat java file that's querying two databases and currently has the credentials hardcoded. The plan is to convert this to spring batch but in the mean time I would like to encrypt them within a config/properties file externally and call them. I'm looking for any specific examples, best practice / solution. I appreciate any time and effort. Thank you!
If you decide to encrypt the credentials, then you have the problem of secure storing the encryption key. The best you can do it to not store it at all and require it to be given manually whenever your application starts up. Your application should use the key to decrypt credentials, connect to any services. Finally it must throw away the key and credentials after use, in order to prevent getting them from memory.
If manual intervention during application startup is unacceptable, then a typical solution is storing the key in a file with appropriately restrictive permissions on an encrypted partition, but if the system gets compromised, e.g. an attacker somehow gets root privileges or privileges of your application, he will be able to recover the database credentials.
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 am in a sticky situation where I am writing an application that sends out emails to clients using an email account of my company. The issue here is that I have to have the password for the account to make the mail service on the server send out emails from that account. I know that passwords should never be stored in plain text, particularly ones that are used for an important email account. The dilemma here is that the program NEEDS to have the actual plain text password to send the emails so it needs to be stored somewhere accessible by the program. The program uses a MySQL database to store information so there are three options in my mind:
1) Store the password in the program's memory, i.e. a private final String field.
2) A file on the on the server where the password can be read from
3) Somewhere in the MySQL database.
I would think that 1 is the safest option, but does anybody have ideas to handle this sort of situation to minimize risk of the password falling into the wrong hands? Thanks for your advice!
The comments pointing out that SMTP doesn't require authentication are correct. That said, all three of the options you specified are insecure, assuming that the server uses commodity hardware and software. I'll show why each is insecure, although I won't follow your original order.
2) A file on the on the server where the password can be read from
3) Somewhere in the MySQL database.
What if someone were to steal the server? Then, they could just open the file or the database, read the password, and immediately have access to all the important information in the company. So unless you have armed guards surrounding the server day and night, this is already pretty insecure.
But it gets worse. No computer system is completely invulnerable to attack, and several well-publicized attacks (Sony's PlayStation Network, for example) in the past few years have shown that an attacker can get to the contents of disk files and databases without physical access. Furthermore, it seems from your question that the server in question is meant to accept packets (HTTP requests, incoming emails, etc.) from the outside world, which boosts your attack surface.
1) Store the password in the program's memory, i.e. a private final String field.
This is tempting, but this is even more pernicious than option 2 or option 3. For one thing, a private final string field is stored in the .class file generated by the Java compiler, so with this option you are already storing the unencrypted password on the server's hard drive. After compromising the server as in option 2 or 3, an attacker can just run javap in order to get the plaintext password out of the .class file.
This approach broadens your attack surface even more, though. If the password is stored as part of the source code, suddenly it's available to all developers who are working on the code. Under the principle of least privilege, the developers shouldn't know extra passwords, and there's a very good reason here. If any of the developers' machines is stolen or compromised from outside, the attacker can look through the compromised machine's hard drive and get the plaintext password. Then there's source control. One of the really important benefits of source control is that it allows you to inspect any prior version of your code. So even if you switch to a secure method in the future, if the password has ever entered source control then the source control server is a potential attack point.
All of these factors add up to show that, even if the HTTP/mail server's security is top-notch, option 1 increases the attack surface so much that the HTTP/mail server's security doesn't really help.
Extra detail: At the beginning I specified "assuming that the server uses commodity hardware and software." If you aren't using commodity hardware and software, you can do things like boot from readonly storage and use only an encrypted database, requiring a person to provide the decryption key on every boot. After that, the decrypted information lives in memory only, and is never written to disk. This way, if the server is stolen, an attacker has to unplug the server and so loses all the decrypted information that was only ever in memory. This kinds of setup is sometimes used for a Kerberos KDC (with the server in a locked boxe for extra security), but is rarely used otherwise, and is frankly overkill when there is an easy way to solve your problem without going to all this extra expense.
If you were serious about keeping it safe, you could encode the password and put it in 2 or 3. When you need to use it, simply have your program decode it and save it in memory as a plain string.
ex.
String encodedUrl = URLEncoder.encode(url,"UTF-8");
String decodedUrl = URLDecoder.decode(url,"UTF-8");
This is a common problem. You can store the password in MYSQL in a blob field applying AES encryption on the insert; using and keeping the key_string in java for handy decryption.
MYSQL Syntax :
AES_ENCRYPT(str,key_str)
and
AES_DECRYPT(crypt_str,key_str)
The insert would be similar to the following:
INSERT INTO t VALUES (1,AES_ENCRYPT('password','encryption_key'));
You would use the key to decrypt coming out
SELECT AES_DECRYPT(password, 'encryption_key') AS unencrypted FROM t
So you never store the password as plain text in your application although you will need the encryption key. Your connection to the database should be secure. Logs may be an issue.
Alternately you could use stored procs to get the keys in and out or you could encrypt them server side and insert/retrieve after encrypted.