I have been asked to secure an Access database at the highest level possible, and something tells me password protecting the file is not sufficient. We have really sensitive data and I need to protect it to the greatest extent possible. Any ideas?
This has been an issue that I have had for several years with Access 2003. We set a Database Password on the database to lock it down so users would need the password to access it. Not necessarily the best option and kind of a pain.
Since you are using MS Access 2007 you might want to check out want Microsoft says are database protection options.
First, when discussing security, we have to define the threat model.
Common threats are:
Unauthorized access of data: Someone that shouldn't be able to read data, is able to read data.
Unauthorized modification of data: Someone that shouldn't be able to modify data, is able to modify data
Unauthorized destruction/corruption of data: Someone is able to vandalize the database
Privilege escalation: Someone who should be able to read or write some of the data, is able to read or write more than intended
Data exfiltration: someone who should be able to read some data is able to copy large amounts of data and move it to an external (or less protected) system.
Malware insertion: someone is able to insert malicious code into the application
The main defense for Access, as discussed, is encrypting the database using a database password. When using an accdb file, this generally offers sufficient protection against unauthorized access and modification of the data. This is a "one privilege fits all" approach, there is one password, if you have it, you have all privileges and can read, write, and insert components at will. Also, when you have write access to the file, but not the password, you are able to damage or delete the file.
A level higher is securing the Access file: using a secure file server to only serve the file to those who should have access to it. This comes with practically all benefits of encryption, and protects against destruction too, as unauthorized users cannot access the file. This also allows us to revoke rights to that folder, assuming the user hasn't made a copy.
If we want to work with user rights, we can separate the file into a front-end file, which does not contain privileged data, and multiple backend files, and secure these files separately, by either using a different password for each file, or storing them on separately secured locations. Again, secure locations offer the additional benefit of protecting against destruction.
Since Access requires users to have write permission to the file (for placing locks) to have read access, however, we can't easily separate read and write permissions this way. One approach I've seen used is using a "shadow folder", where a virtual folder is created for read users, and upon accessing the folder, the most recent database file is placed in it, and overwritten each time. Setting this up, however, is nontrivial.
Another approach which is very common is trying to use VBA to limit which actions users can take, and allowing them only to open specific forms and take specific actions on them. This is possibly combined with tricks like disabling the bypass key, and/or creating a compiled copy (accde/mde) without the original code. However, these will only stop novice attackers, and can practically always be bypassed, either by using a non-Access program to read the data (which will ignore any restriction imposed by VBA), allowing the bypass key through COM, disabling VBA altogether on the machine, etc. A compiled database only makes it impossible to view and modify the code, not the data, and this also can be bypassed by experts by manually reconstructing the code (example commercial service that offers this). Thus, while this may look like proper security at first glance, it has severe flaws.
Compiling the code is useful when combined with signing the code, to protect against unauthorized malware insertion. Since a decompiled, modified and then recompiled copy won't have a valid signature, assuming the attacker can't access the trusted certificate used to sign the code, and systems can be configured not to open compiled databases without that signature, this can help detect malicious modification of the database.
If we want to have separate user privileges, but cannot enforce this using separately secured folders, an option is to have separately encrypted backends with different keys. For usability purposes, we can use a key encryption key to have a separate password for each user, and have that password grant access to the backends which the user is allowed to use. I've created a sample of a database that uses key encyption keys for this Q&A, but nowadays I'd make some changes, such as using a single front-end with both the KEKs and linked tables to the encrypted databases, and using the CNG API for fast encryption in VBA.
Note that some of these options add a lot of complexity, and none properly protects against data exfiltration (which is an increasing threat in the country + sector I work in). Often, it's a lot more simple, in terms of infrastructure, management, etc. to use a different back-end than Access. This can still allow you to use Access as the front end, so users might not even notice a change, but management of permissions is determined by the back end, which can either be secured by using different passwords for each users, or, in case of SQL server, by linking security to an AD domain (SSPI).
In SQL server, we can also add logging, restrict fetching large datasets by only granting rights to stored procedures and limit the amount of requests over time, to mitigate data exfiltration. However, the added complexity this brings to using Access as a client often makes choosing a different client more sensible, if you only use stored procedures linked tables are not available and Access tends to make more requests than necessary.
Note that when choosing to use a different back-end, it is still recommended to compile and sign the Access database to mitigate malware insertion, which is not dependent on the back-end used.
Bonuses:
What about user-level security? That was a technology specifically intended to offer per-user read and write rights, and separate rights for modifying the database and managing users. Unfortunately, it was insecure and there are many tools out there to remove it, and it only applies to the mdb and mde database formats, so is not of any use.
And, of course, you can also secure the user by securing the environment that Access runs in. I've seen a deployment where users are only allowed to access resources in a virtual environment that is behind a firewall disallowing all internet access, is limited to only opening this specific database, doesn't allow storage devices, and doesn't share the clipboard with the main environment. That allows you to have a secure database by using VBA, but severely limits usability of the database (especially the copy-paste limitation frustrates users, but copying and pasting could be used for data exfiltration).
I would suggest you put it on a file server and have a strict access control list.
In the database force users to log in then
add triggers to write out audit info when a record changes (with the user info,date/time).
Related
I am developing a new app that target Windows 8 upwards. It generates and downloads sensitive documents which should only be accessible from the app after logging in.
Since the Windows filesystem is open to Explorer, is there a way to only allow access through my app?
I have already read a bunch of blog posts that talk about how the app is limited in a sandbox so that it can't affect the wider OS, however none have discussed having a secure directory that is not accessible from outside the app.
As a first note, if you allow users to download data to devices they control, and your program can access it, they will be able to access it. In your context, you would want to worry less about benign users accessing it, and worry more about malware and malicious users. With that in mind, you have two goals:
Restrict access to files such that only my application can access them
Restrict access such that my application only has access when the intended user is using it.
There are likely several viable methods of attaining those goals; but as a crypto geek, I of course recommend cryptography. In brief, you can use cryptography to attain these goals in this manner:
When your program initiates, have it generate a random key and store it in an accessible location on disk. Before storing it, use some user-specific secret (like their password) to encrypt the key itself.
When a user downloads a file, encrypt it with the key you have stored. When a user accesses a file, decrypt it with the aforementioned key.
This ensures that the plaintext of the documents is never stored on disk, only in memory, and that an attacker cannot simply steal the key along with the documents. Note that, however, the plaintext key and documents will exist in memory, and a sufficiently sophisticated attacker could be able to retrieve them if they had access to the system while a legitimate user was using your program.
I am currently working on a java search project that will be distributed to the clients' local server, the project contains some valuable data that we hope it cannot be accessed directly on the machine, but can only be accessed from the project services/apis. The data will be updated on a daily basis and need to be avaliable for query 24/7.
I am thinking of eCryptFs, but after some test, it seems that once the encrypted data is mounted under the service user, say 'root1', as I have to keep the encrypted data in the mounted state to support query, all the other login users can access the de-crypted data without password. Is there anyway to support my scenario? Thanks.
If your users don't have root access, you can simply store the encryption key in a file and deny read access to other users.
If your users do have root access, there is nothing you can do.
EDIT:
Under most circumstances, someone with root account can do anything that the other users can do. So, even if you did get per user r/w permissions on a file but only for a certain user (which is very possible), it would be rather pointless. (Someone with sudo/root access could just run sudo su USER, where USER is the account with the r/w permissions. I think a better way to go about this is to look at options that users do not have control over.
The first thing that came to mind was compiled programs. While they are not really meant for holding secure information, you could compile a simple program to output a little bit of the information after a time delay (to prevent them from just running it continuously and then compiling all of the data they get from it.) Actually, modifying your Java program might be easier; just have it store the information as an enormous string or something. :D
These open source Java obfuscators will make it harder (but certainly not impossible) to reverse engineer your program and, along with it, the data inside.
A more secure option would be to write a C program, compile it, and have it output information (after a time delay) that the JAVA file can then manage. In order to make it harder to decompile, you could add some encryption methods to the string so if the Decompiler messes up on any part of it, it's still worthless information to them.
Final verdict: Nothing is really 100% secure when it is stored on someone else's computer(s) but, then again, neither is it 100% secure on your own server. I would suggest looking into other options, but if you have no other option and you have legal protection on the information, this might work for you.
I have programmed a system for internal behavior reporting for my company's intranet. I should not have access to its data (not being part of the controlling committee, but I have.
I've locked my account away from the data, but I could unlock it. I could store the data in an encrypted format, but, even if chosen by someone else, I should store the salt somewhere and hence read it -> decrypt the data.
From a theoretical point of view (I'm not talking about a particular system or framework or utility), how can I not have access to the data stored in a system I have complete control of?
Seems to me that you could just set passwords such that only one user has access to the database, then allow someone else to set that password. It would make maintenance a bit more tricky, but then again a database shouldn't need a ton of maintenance on a tool like this once all is said, done, and thoroughly tested.
If this is internal, it would be nothing to setup a dedicated, physically secure WAMP or similar machine that's solely dedicated to this purpose. Have someone else tweak root passwords and store them with the "committee" and you're off the hook, in theory.
I suppose if one was to be completely paranoid, one could build a web service to isolate the database completely on a separate network from the reporting functionality. In theory, you could setup the web service on a remote machine that your access is removed from, then use the front-end to collect data and pass it to the webservice. From there, it's completely out of your hands, with no "data out" webservice to retrieve data.
Security is always a messy subject. I've worked in banking, ecommerce, and sports (drug testing) environments where I'm knee-deep in confidential data and it is more than just a bit scary. At some point, you just have to do the best you can do, document your safeguards, be "read in" on proper protocol and required background checks, do thorough testing with independent testers, and then just maintain complete transparency. In the IT world we have access to a ridiculous amount of information, and that's never going to go away.
The basic answer is Mandatory Access Control. The kind of access control most computer user are familir with is Discressionary Access Control. In DAC (Discressionary Access Control) everything on the computer is owned by a user. Users can grant access of an object (file, service, peripheral, memory, etc) to another user. Users can even transfer ownership of an object to another user. In MAC (Manditory Access Control) at least some objects are not owned by any user. The rules governing how users can access or interact with these objects are fixed and unchangable by any user.
In your example the data generated by the reporting system should be protected by Manditory Access Control, but the reporting system configuration may be owned by you. So you can control how the system behaves but not have access to the data it generates.
Microsoft began implementing MAC with Windows Vista. In Vista it was called Mandatory Integrity Control (MIC).
Linux can implement MAC with SELinux or AppArmor.
Mac OS X uses an implementation of the TrustedBSD MAC.
So, why isn't MAC used more often?
I takes effort. It is not easy to set up MAC, and it is hard to change once it is set up. It can be complicated. Most systems and services are built on the DAC model. Turning on MAC often makes services stop working.
Just a general architecture question.
I know that for web sites, one can use the features built in to IIS to encrypt the connection string section. However, what I am not certain of is this... If I do this and then copy the web.config to another project, will the new project still be able to decrypt the connection strings section in the config file?
Where this becomes an issue is production database access. We don't want anyone to be able to copy the config file from production into their project and have carte blanche access to the production database.
Currently the way my company does it is to store the encrypted connection string in the registry of the server, then use a home-grown tool to read the registry and decrypt the value on the fly. This prevents someone from just looking into the registry or web config to see the connection string.
Further, for thick client (WinForms, WPF, etc.) applications, this could be a little more problematic because once again, I am unsure if the IIS encryption trick will work since the applications would not be running on IIS. We currently have a kludgy solution for this which involved the same home-grown application, but reading the encrypted string from a binary file and decrypting on the fly.
It just seems very patched together, and we are looking for a better way to do it (i.e., industry standard, current technology, etc.)
So, a more general question is this...
What approaches have you used for securing your connection strings? Especially when it comes to multiple application types accessing it, encryption, etc.
A quick Google search will show you other people's attempts at encrypting some or all of an application configuration file (i.e. Google "ecnrypting application configuration files").
But more often than not, I find that the better answer is properly securing the resource that you are concerned about (usually a database). Windows authentication is always preferred of SQL authentication, that way passwords do not need to be stored in the config file, though this may not always be an option. If you want to prevent access to a resource (especially if it's usually accessed through any sort of web layer, like a web service or a website itself), then host the resource on a different server (which is preferred anyways) and don't allow access to it from outside your internal network. If the attacker has access to your internal network, then there's usually bigger concerns than this one resource you are trying to protect.
If you are concerned about a malicious person performing an action that even your application can't perform (like dropping a database), then ensure that the credentials the application is using doesn't have that type of permission either. This obviously doesn't prevent an attack, but it can reduce the amount of damage that is done from it.
Securing information stored in a configuration file that is located on the user's machine is generally not worth the time, IMHO. At the end of the day, the machine itself will need to be able to decrypt the information, and if the machine has the means to do it, then so does the user. You can make it hard for the user to do it, but it's usually still doable.
This isn't really a direct answer to your question, but I hope it gets you thinking down a different path that may lead to an acceptable solution.
From my understanding the protection of encrypted connection strings as for example presented in the article Importing and Exporting Protected Configuration RSA Key Containers protected the connection string on a user-level.
This means that only the account running IIS (NT AUTHORITY\NETWORK SERVICE) can access the cryptographic keys for decrypting the connection string. Therefore this protected only against users who are able to log-on onto the server holding the web.config file. But it can be extended to limit access to certain application.
Regarding the fat client there may be a way to narrow down the interface a bit:
Define all SQL commands as stored procedures on the server and change the settings for the used user account to only allow executing those stored procedures. This would limit access to the database to operations that can be performed using the SQL login credentials.
I would use the SQL DB account management features, with specific permissions only (e.g. at it's most abstract - allow the execution of read only SQL commands) and only from allowed hosts and/or realms.
So I have a web application that integrates with several other APIs and services which require authentication. My question is, is it safe to store my authentication credentials in plain text in my source code?
What can I do to store these credentials securely?
I think this is a common problem, so I'd like to see a solution which secures credentials in the answers.
In response to comment: I frequently use PHP, Java, and RoR
I'd like to see some more votes for an answer on this question.
Here's what we do with our passwords.
$db['hostname'] = 'somehost.com'
$db['port'] = 1234;
$config = array();
include '/etc/webapp/db/config.php';
$db['username'] = $config['db']['username'];
$db['password'] = $config['db']['password'];
No one but webserver user has access to /etc/webapp/db/config.php, this way you are protecting the username and password from developers.
The only reason to NOT store the PW in the code is simply because of the configuration issue (i.e. need to change the password and don't want to rebuild/compile the application).
But is the source a "safe" place for "security sensitive" content (like passwords, keys, algorithms). Of course it is.
Obviously security sensitive information needs to be properly secured, but that's a basic truth regardless of the file used. Whether it's a config file, a registry setting, or a .java file or .class file.
From an architecture point of view, it's a bad idea for the reason mentioned above, just like you shouldn't "hard code" any "external" dependencies in your code if you can avoid it.
But sensitive data is sensitive data. Embedding a PW in to a source code file makes that file more sensitive than other source code files, and if that's your practice, I'd consider all source code as sensitive as the password.
It is not to be recommended.
An encrypted web.config would be a more suitable place (but note can't be used with a web farm)
It appears the answer is the following:
Don't put credentials in source code but...
Put credentials in a configuration file
Sanitize log files
Set proper permissions/ownership on configs
Probably more depending on platform...
No, it is not.
Plus, you might want to change your password one day, and probably having yo change the source code may not be the best option.
No. Sometimes it is unavoidable. Better approach is to have an architecture set up where the service will implicitly trust your running code based on another trust. (Such as trusting the machine the code is running on, or trusting the application server that is running the software)
If neither of these are available, it would be perfectly acceptable to write your own trust mechanism, though I would keep it completely separate from the application code. Also, would recommend researching ways to keep passwords out of the hands of predators, even when stored on local machine - remembering that you can't protect anything if someone has control of the physical machine it is on.
If you control the Web server, and maintain it for security updates, then in the source (preferably in a configuration module) or in a configuration file that the source uses is probably best.
If you do not control the Web server (say, you are on a shared or even dedicated server provided by a hosting company), then encryption won't help you very much; if the application can decrypt the credentials on a given host, than the host can be used to decrypt the credentials without your intervention (think root or Administrator looking at the source code, and adapting the decryption routine so that it can be used to read the configuration). This is even more of a possibility if you are using unobfuscated managed code (e.g., JVM or .NET) or a Web scripting language that resides in plaintext on the server (like PHP).
As is usually the case, there is a tradeoff between security and accessibility. I'd think about what threats are the ones you are trying to guard against and come up with a means to protect against the situations that you need. If you're working with data that needs to be secure, you should probably be redacting the database fairly regularly and moving data offline to a firewalled and well-protected database server as soon as it becomes stale on the site. This would include data like social security numbers, billing information, etc., which can be referenced. This would also mean that you'd ideally want to control the servers on your own network which provide billing services or secure data storage.
I prefer to keep them in a separate config file, located somewhere outside the web server's document root.
While this doesn't protect against an attacker subverting my code in such a way that it can be coerced into telling them the password, it does still have an advantage over putting the passwords directly into the code (or any other web-accessible file) in that it eliminates concern over a web server misconfiguration (or bug/exploit) allowing an attacker to download the password-containing file directly.
One approach is to encrypt The passwords before placing the password in config.web
I'm writing this for web service app that receives password, not client:
If you save hashed passsword in source code someone who views the source code won't be able to help himself with that hash.
Your program would receive plain password and hash it and compare both hashes.
That's why we save hashed passwords into databases, not plain text. Because they can't be reversed if someone for example steals db or views it for malicious purposes he won't get all users passwords, only the hashes which are pretty useless to him.
Hashing is 1 way process: it produces same value from same source but you can't compute source value out of hash.
Storing on client: when user enters pass u save it to db/file in plaintext, maybe obfuscate a little but not much u can do to prevent someone who gets a hold of that computer to get that password.
Nobody seems to have mentioned hashing yet - with a strong hash algorithm (ie SHA-2 and not MD5), it should be much safer.