I'm going to create a Java Application for collecting some enterprise information.
My problem is the DBMS security.
EDIT: My Application is not connected to Network and the whole DB and App. are located on the system that app. is accessed from there; Users has ACL so I don't want a user be able to read data that hasn't access to them by using database files on the disk.
I need a DBMS that encrypt data on disk to protect data against someone with a Text/HEX editor or other SQL Browsing Tools (Like SQLite that has no security mechanism or ...)!
Which DBMS can I use to be sure that data are accessible only through my application (and of course DBMS itself) and not directly from the disk?
Does MySQL or PostgreSQL have such a direct disk access protection mechanism?
Thanks
If the individual has access to the disk itself, there's a good chance that he will have access to the code and other data of your application. And the encryption key (used to encrypt the DB file) will be available as well. This problem doesn't have a universal solution (see one approach below) if the computer device gets into wrongdoer's hands.
Putting the above aside you have several options:
SQLite has whole-DB encryption plugin.
You can mount the disk using TrueCrypt or one of its alternatives
We have several products (namely SolFS and CallbackFilter) which let you encrypt the DB file on the fly either using the virtual disk (SolFS) or by encrypting/decrypting files on the fly by filtering file I/O requests (CallbackFilter).
If you are able to have the user provide a password / key in some way, then you can use a session key to encrypt the database data, and then encrypt this session key using each user's password. Then, when the user wants to access the data, you ask him for a password, decrypt the session key and use the key to access the DB. In this way the key used to encrypt the data is not stored in "cleartext" and getting physical access to the disk doesn't reveal the data.
Related
I have a web app that uses known username and password combinations to login to external servers. There are multiple username/password combinations used for different services. Right now, they are essentially "hard-coded" into the website code, but, I would like to move this information off the code base for better security.
My initial thought is to store this data in the database which is used to support the website. I want to store it in a way that it is not easily "hackable" (i.e. I'm not going to store it as plain text or as a MD5 hash). Should I follow the same format that I use to store the website user's passwords, where I use a random number generator to create SALT for each password and then store the password as hashed combination of the password and SALT, or would this be overkill?
Generally, storing passwords in the application code is always a bad idea. Moving it outside the code has many advantages including security.
Now storing it either in DB or Configuration Files is a choice you have to take depending on your application.
For full security you should never store passwords in retrievable form. But to login to a external server as in your case, you need to get the actual plain text password, so one way hash will not work for you.
In our product we deal with such situation by using 2 Way SSL Certificates. It is very secure and there is no need to store the passwords.
But if you really need to store the passwords, then I will suggest to use configuration file and let your application read it. You can encrypt the passwords stored in the configuration files (Encrypting the passwords stored in the configuration file will again bring you back to the same question of how to protect the key). The access to the configuration file should be restricted (in Unix, 600 File Permission).
Alternatively, if your web application is Java, then you can consider using JNDI.
After more research, I've decided at this point to follow the ideas here:
Encrypt a Column of Data - SQL Server | Microsoft Docs
...and encrypt/decrypt on the DB inside a Stored Procedure.
I'm storing options data in a chrome extension using chrome.storage.local.set
How secure is that data?
Can it be read easily by anyone who has access to the file it is stored in?
It is not secure, and per the official chrome.storage docs is stored unencrypted in the user's profile folder under their Chrome data directory. You will need to use some additional encryption if you are storing more sensitive data using these APIs.
They are stored in a LevelDB database in the following location:
C:\Users\<User>\AppData\Local\Google\Chrome\User Data\Default\Local Extension Settings\<Extension id>
It's saved in the following path (For other OS, the path is similar), can be easily accessed.
C:\Users\<User>\AppData\Local\Google\Chrome\User Data\Default\Local Extension Settings\<Extension id>
Basically, since the data is saved in local machine, you can't trust it as secure, since there're tons of ways to get the data. For example, other extension/scripts may overrite chrome.storage.local.set and they may get the data first, like what Storage Area Explorer does.
I need to store an encryption key locally in order to allow a user to use my CouchApp in a disconnected mode. The data that I will be sending is very sensitive and requires encryption by law. However, we would like to offer full access to data when running disconnected. Currently we have a password key generator, but this would require the user to enter their password every time they want to view a record. Also this doesn't seem to be secure as an experienced/advanced user could potentially access the encryption key, and then the Local Database. I'm basically wondering if anybody has experience with the disconnected security model, or if you can offer any pointers on how to allow access while maintaining security.
If your client is connecting directly to the database then all users have access to the entire data set. Apparently you trust your users... with everything. This feature right here breaks the most common data protection models. An attacker doesn't need sql injection or insecure direct object reference, he can just grab whatever he because you are giving him everything.
I don't see how cryptography solves your problems. It looks like a textbook CWE-602 violation.
Here's the situation: we have a common library which can retrieve database connection details from a central configuration store that we have setup. Each application uses this library when working with a database.
Basically, it will call a stored procedure and say "I am {xyz} application, I need to connect o " and it will return the connection details for that applications primary database (server, instance, database, user, and password).
How would one go about locking that down so that only application {xyz} can retrieve the passwords for {xyz} databases (there is a list of database details for each application... i just need to secure the passwords)?
The usual way is to have a different config store per app and give each app a different user/password to connect to the config store.
That doesn't prevent anyone from changing the app and replacing the user/password for app X with the values from app Y but it's a bit more secure, especially when you compile this data in instead of supplying it via a config file.
If you want to be really secure, you must first create a secure connection to the store (so you need a DB drivers that supports this). This connection must be created using a secure key that is unique per application and which can be verified (so no one can just copy them around). You will need to secure the executable with hashes (the app will calculate its own hash somehow and send that to the server who will have a list of valid hashes for each app).
All in all, it's not something trivial which you can just turn on with an obscure option. You will need to learn a lot about security and secure data exchange, first. You'll need a way to safely install your app in an insecure place, verify its integrity, protect the code against debuggers that can be attached at runtime and against it running in the virtual machine, etc.
Off the top of my head, try PKI.
Are you trying to protected yourself from malicous programs, and is this a central database that these applications are connecting to? If so you should probably consider a middle layer between your database and application.
I'm not sure this applies to your case, depending on how what your answers to the abovementioned would be, but by the comments it sounds like you are having a similar case to what this question is about.
Securing your Data Layer in a C# Application
The simplest/most straightforward way would be to store the passwords in encrypted format (storing passwords in plaintext is just plain bad anyhow, as recently demonstrated over at PerlMonks) and make each application responsible for doing its own password encryption/decryption. It would then not matter whether an app retrieved another app's passwords, as it would still be unable to decrypt them.
One possibility is to keep the passwords in the database in an encrypted form, and convey the encryption key to the allowed application(s) in a secure connection.Then, only the application with the encryption key can actually get the passwords and not others.
I have a database that contains sensitive information. I can encrypt / decrypt the data on the read write operations. The problem is that I need to store the key in the application. If someone has hacked their way in such they have access to the database then they can also grab the application (java) decomplie it and pull the key.
This seems like a speed bump at best. What other solutions are available?
The only thing you can do is make it difficult to extract the key from your application. You can't make it impossible. If you give someone a box with contents that you're trying to protect, you have to give them the key if you want them to be able to access the contents. Once you give them the key they can do whatever they want… if they take the trouble of finding the key.
This is a case of Bob and Eve being the same person, you want to give Bob access but stop Eve from seeing it.
This is DRM, it doesn't work.
I am assuming you have some way to verify the credentials of the user before allowing them to access the database?
Usually the architecture for these kinds of things is as follows:
Database
Server
Client
The Client connects to the Server, which then connects to the Database.
The Server makes sure the Client authenticates correctly before allowing them access to sensitive information. The decryption key is stored only on the server. Noone should have access to the server, and especially the file that contains the key. This way the clients do not have any encryption/decryption they have to do, and do not have to store any keys.
Read up on keystores.
Require the user to enter a passphrase to access their data. Burying the key in the code is security by obscurity.
Store the keys in a CSP container. Consider the Java CSP here .
This is IMO the safest way possible. But you can also consider storing the key in a file which is protected by the operating system using some kind of ACL.
require the user to log in using a strong password; use the password as the key for a symmetric encryption algorithm to decrypt the asymmetric database key
keep the db key in secure memory while the application is running (if that is an option)
Encrypt the key (using DPAPI), put it in a file, put an ACL on that file etc...