In Windows would it be possible to protect data within a single program? I have been looking into CryptProtectData but whis is by user basis I would like something simular but on program basis. My program will have multiple users that require access to the same data, but the data is sentitive and I dont want any user to read it.
First of all, if your user has administrator privileges, there is no definite way to keep them out.
Second, even if they didn't, you'd have to implement part of your software at ring 0, so it would have a higher privilege than the user, which would make it harder for them to get access to the process' memory or executables. You could then encrypt your data and decrypt it when you serve it to the user.
If all of the above is not possible, you can employ the same obfuscation techniques that software developers use against cracking.
That usually comes down to preventing debugging or preventing patching. Some advice here: http://www.woodmann.com/crackz/Tutorials/Protect.htm
CryptProtectData (indirectly) uses user's credentials to encrypt the data.
On Windows (as well as on most other general-purpose computer platforms) it is not possible to encrypt the data on per-application basis cause the computer belongs to users and the user is the master, not the application.
If you don't want the data to be accessible for the user (and other applications running under user's account), you need to move this data out of the computer, store it on the remote system and control user's access to this data.
If your users do not have administrator privileges then what I would do is have your program create an account for its own purposes. When your program creates its data files, it would set the ACLs on those files so that the account it created is the only one with any access to those files. Whenever your program needed to read/write those files, it would need to temporarily login using its special account. The problem is then to keep the login credentials for that account secret. That's another problem entirely.
Related
When writing an application based on Datomic and Clojure, it seems the peers have unrestricted access to the data. How do I build a multi-user system where user A cannot access data that is private to user B?
I know I can write the queries in Clojure such that only user A's private data is returned... but what prevents a malicious user from hacking the binaries to see user B's private data?
UPDATE
It seems the state of Clojure/Datomic applications is in fact lacking in
security based on the answer from #Thumbnail and the link to John P Hackworth's blog.
Let me state more clearly the problem I see, because I don't see any solution to this and it is the original problem that prompted this question.
Datomic has a data store, a transactor, and peers. The peers are on the user's computer and run the queries against data from the data store. My question is:
how to restrict access to data in the data store. Since the data store is dumb
and in fact just stores the data, I'm not sure how to provide access controls.
When AWS S3 is used as a data store the client (a peer) has to authenticate
before accessing S3, but once it is authenticated doesn't the peer have access
to all the data!? Limitted only be the queries that it runs, if the user wants
to get another user's data they can change the code, binary, in the client so
that the queries run with a different user name, right? To be clear... isn't
the access control just a condition on the query? Or are there user specific
connections that the data store recognizes and the data store limits what data
is visible?
What am I missing?
In a traditional web framework like Rails, the server side code restricts all
access to data and authenticates and authorizes the user. The user can change
the URLs or client side code but the server will not allow access to data unless
the user has provided the correct credentials.
Since the data store in Datomic is dumb, it seems it lacks the ability to
restrict access on a per user basis and the application (peer) must do this. I
do not want to trust the user to behave and not try to acquire other users'
information.
A simple example is a banking system. Of course the user will be
authenticated... but after that, what prevents them from modifying the client
side code/binary to change the data queries to get other users' account
information from the data store?
UPDATE - MODELS
Here are two possible models that I have of how Datomic and Clojure work... the first one is my current model (in my head).
user's computer runs client/peer that has the queries and complete access to the data store where user was authenticated before the client started thereby restricting users to those that we have credentials for.
user's computer has an interface (webapp) that interacts with a peer that resides on a server. The queries are on the server and cannot be modified by the user, thereby access controls are under access control themselves by the security of the server running the peer.
If the second model is the correct one, then my question is answered: the user cannot modify the server code and the server code contains the access controls... therefore, the "peers" which I thought resided on the user's computer actually reside on the application server.
Your second model is the correct one. Datomic is designed so that peers, transactor and storage all run within a trusted network boundary in software and on hardware you control. Your application servers run the peer library, and users interact with your application servers via some protocol like HTTP. Within your application, you should provide some level of user authentication and authorization. This is consistent with the security model of most applications written in frameworks like Rails (i.e. the end user doesn't require database permissions, but rather application permissions).
Datomic provides a number of very powerful abstractions to help you write your application-level auth(n|z) code. In particular, since transactions are first-class entities, Datomic provides the ability to annotate your transactions at write-time (http://docs.datomic.com/transactions.html) with arbitrary facts (e.g. the username of the person responsible for a given transaction, a set of groups, etc.). At read-time, you can filter a database value (http://docs.datomic.com/clojure/index.html#datomic.api/filter) so that only facts matching a given predicate will be returned from queries and other read operations on that database value. This allows you to keep authz concerns out of your query logic, and to layer your security in consistently.
As I understand it ... and that's far from completely ... please correct me if I'm wrong ...
The distinguishing feature of Datomic is that the query engine, or large parts of it, reside in the database client, not in the database server. Thus, as you surmise, any 'user' obtaining programmatic access to a database client can do what they like with any of the contents of the database.
On the other hand, the account system in the likes of Oracle constrains client access, so that a malicious user can only, so to speak, destroy their own data.
However, ...
Your application (the database client) need not (and b****y well better not!) provide open access to any client user. You need to authenticate and authorize your users. You can show the client user the code, but provided your application is secure, no malicious use can be made of this knowledge.
A further consideration is that Datomic can sit in front of a SQL database, to which constrained access can be constructed.
A web search turned up Chas. Emerick's Friend library for user authentication and authorization in Clojure. It also found John P Hackworth's level-headed assessment that Clojure web security is worse than you think.
You can use transaction functions to enforce access restrictions for your peers/users. You can put data that describes your policies into the db and use the transaction function(s) to enforce them. This moves the mechanism and policy into the transactor. Transactions that do not meet the criteria can either fail or simply result in no data being transacted.
Obviously you'll need some way to protect the policy data and transaction functions themselves.
I am writing a C++ application with a postgresql 9.2 database backend. It is an accounting software. It is a muti user application with privilege separation features.
I need help in implementing the user account system. The privileges for users need not be mutually exclusive. Should I implement it at the application level, or at the database level?
The company is not very large at present. Assume about 15-20 offices with an average of 10 program users per office.
Can I make use of the roles in postgres to implement this? Will it become too tedious, unmanageable or are there some flaws in such an approach?
If I go via the application route, how do I store the set of privileges a user has? Will a binary string suffice? What if there are additional privileges later, how can I incorporate them? What do I need to do to ensure that there are no security issues? And in such an approach I am assuming the application connects with the privileges required for the most privileged user.
Some combination of the two methods? Or something entirely different?
All suggestions and arguments are welcome.
Never provide authorization from a client application, which is run on uncontrolled environment. And every device, that a user has physical access to, is an uncontrolled environment. This is security through obscurity — a user can simply use a debugger to get a database access credentials from client program memory and just use psql to do anything.
Use roles.
When I was developing an C++/PostgreSQL desktop application I've chosen to disallow all users access to modify all tables and I've created an API using Pl/PgSQL functions with VOLATILE SECURITY DEFINER options. But I think it wasn't a best approach, as it's not natural and error prone to use for example:
select add_person(?,?,?,?,?,?,?,?,?,?,?,?);
I think a better way would be to allow modifications to tables which a user needs to modify and, when needed, enforce authorization using BEFORE triggers, which would throw an error when current_user does not belong to a proper role.
But remember to use set search_path=... option in all functions that have anything to do with security.
If you want to authorize read-only access to some tables then it gets even more complicated. Either you'd need to disable select privilege for these tables and create API using security definer functions for accessing all data. This would be a monster size API, extremely ugly and extremely fragile. Or you'd need to disable select privilege for these tables and create views for them using create view with (security_barrier). Also not pretty.
I am developing an application that works with PostgreSQL and other database features that require a username and password to login to the remote server to store the data. The user has to be able to set the username and password which would then be stored in a configuration file on disk. The problem is that anybody can open the configuration file and read the credentials creating a serious security problem.
I have done some research on encrypting the whole configuration file and then de-crypting it when needed, but the problem is that a hacker could put the program though a debugger and easily find out the decryption key. What is the best method to keep configuration data secret on Windows using C/C++?
The moment an Attacker is able to attach a debugger to your running program is the moment the game is over. Being able to debug your program means that your user account or the underlying OS is compromised, which means every security measure on your app's behalf is futile. The attacker will (with knowledge, persistence and motivation) know everything you enter into your computer, or have entered and stored before.
The user has to be able to set the username and password which would
then be stored in a configuration file on disk
This is the weak spot and this is what you need to change.
(On a side note, is the password you store never going to change? That's another security weak spot.)
As stated in Eugen Rieck's answer, if the attacker has physical access to your system he will, in time, break all your defenses.
The simple solution is clear: don't let him have access to the system that handles security/authorization. Have the SQL server on a dedicated, remote machine and let it handle the username/password validation.
Or, make your app multi tiered with part on a remote machine that handles the user authentication and routs your DB queries.
This will mean that your user will have to login every time they start your application.
(Preferably also after a pre-set period of inactivity.)
It all depends on how safe you need to be. It's important to understand that security is not easy to create and you should always try to use existing frameworks if possible.
In a Django project, I want to keep user uploaded files secure on the server. Should this be done at the OS level (we are using ubuntu) or at the application level?
Encrypting at the application level will be easier to maintain. But, aside from some drawbacks like possible negative effect on performance, I am not even sure if this will have any point. If a hacker compromises the server, he will also have access to the encryption keys and how it is encrypted / decrypted.
Any suggestions are greatly appreciated. Thanks.
How you protect your data depends on what kinds of attacks you want to protect against. Of course, you probably don't know how an attacker is most likely to compromise your system, unless there are certain threat models you're particularly trying to protect against, like say a rogue sysadmin.
The attacker might gain access to the OS that the web server is running on. In this case, filesystem level encryption probably does you no good. In fact file-system level encryption is probably only useful protection against somebody walking off with the physical server (which is a totally valid threat model). However, if the files are encrypted with keys stored in the database, then an attacker who has access to the webserver OS but not the database is thwarted.
In contrast, an attacker might gain access to the database but not the OS, through a hole in your application. I would expect this to be less likely since modern operating systems present huge and well-studied attack surfaces.
To protect your user's data against an attacker with full access to your servers is very difficult. You need to encrypt the data with a key that your servers don't have. This could be something like a password or a key stored in a user cookie. The problem with all these schemes is that users can't be trusted to hold on to critical data like this -- they always want a way to reset their password if they forget. In most cases, it's not realistic to protect data against an attacker with full access to your OS and your database.
So I'd choose what you're trying to protect against. Personally, I'd expect an OS penetration to be most likely, and thus encrypt the files with keys that are stashed in a part of the database that is extra protected somehow. The challenge here is that the OS has to store database login credentials (in settings.py) in order for the web app to function. So try to keep those files as restricted as possible within the OS i.e. chmod 600 on a user account that does as little else as possible.
You're right that if the key used to encrypt the files is stored on the server you don't get a whole lot of added security by encrypting the files.
However, if you use a key provided by the user, then you do get some security. For example, if you store the encryption key in a cookie, then it will only be available for the duration of each request. I don't believe this will create any new security issues (if an attacker can steal the cookie, they can also steal the user's session), and it will make it much harder for an attacker to access files belonging to users who aren't currently online.
If you're really paranoid, you could do what 1Password does, and send encrypted data back to the browser, which can decrypt it with JavaScript encryption routines…
I've written a small service (plain Win32) and I'd like to know if it's possible to run multiple instances of it when multiple users are logged on.
Basically, let's say we've got UserA and UserB for UserA the service would log on as "domain\UserA" and for UserB the service would log on as "domain\UserB" - this is from the same executable of course. I can change the logon dynamically using the ChangeServiceConfig() function, but it changes it system-wide it seems, while I'd like each user to have his own copy of the service running only for him.
Thank you in advance for any pointers.
Win32 services are designed to be system-wide, and start running before any user is logged in. If you want something to run on a per-user basis, it's probably better to design it as a regular application and run it from the user's Startup group.
Is it possible to perhaps have the service create child processes which then adopt the user credentials (or be started with them)? This way you're still limited to a single instance of the service, but it is able to do its per-user jobs all the same. IIRC the Windows Task Scheduler service does this.
The whole concept of a service is that it is started before any user is even logged on. so even if this was possible, you wouldn't be able to choose between userA and userB when the service starts because none of them is logged on yet.
A possible direction would be for the service to run as SYSTEM And every few minutes check if there is a user logged in, if there is- impersonate that user and do this stuff.
Yes, that sounds close (I'm answering comment from Greg, but comments are too short to fit my reply).
I don't know the list of users beforehand, but there's a GUI control application that would be used to enter username/password pairs for each user. So, userA would log on, run the application, enter his credentials and service would use that. At the same time (after userA has logged off, but the service is still running with userA's credentials) userB logs on, uses the app, and another copy of the service starts running as logged on userB. Thus, at the same time userA and userB services are running.
Is that possible?
You are probably looking to Impersonate the users. Check out some references I found with a quick Google search here:
MSDN Article on WindowsIdentity.Impersonate
.Net Security Blog Article
It sounds as if you actually have two different, conflicting requirements, as to timing and identity.
Run as each logged in user
Run automatically even if no user is logged in.
No way to do this trivially, instead consider wrapping your program in a service; the program will run normally on startup for each user (either thru the startup folder or taskscheduler), and in addition create a service to run your app as a system user (or any other user you define).
Since you also need (you mention this in the comments) the app to keep running as the enduser even after he logs out, you can have the service manage this process for you.
HOWEVER this might not be the best idea, since the user is still effectively logged in. This can have numerous side effects, including security, performance (too many users logged in at once...), etc.
You could create an service application and a non-service(normal) application and make them communicate through IPC (Mapped File, Pipes, MailSolts ... you name it).
This way you solve all the troubles.
NOTE: The same application can behave differently - when started as a process and when started by a user, but in the end it is the same thing, you still have 2 applications (no matter if you got only one executable).
Running with different accounts is possible. In fact, this is common. See svchost.exe, which implements a bunch of OS services.
I just don't get how you determine which accounts. In a big company, many PCs are set up so all 100.000+ employees could use it. You don't want to run your service as the logged-in users, nor can you want to run it for all 100.000 users. So for which accounts, I have to ask?
A Windows process can only execute with the privileges of one single user at a time. This applies to services and other processes. With enough privileges it is possible to "switch" between different users by using impersonation. The most common pattern for what you are trying to do is to have one instance of a privileged service which registers to log in/log out events and creates children processes accordingly, each one of them impersonating the logged in user. The pattern will also simplify UI as each process runs on each separate user's Desktop, as if it were a regular application.
If you keep the privileged service's code as simple as possible this pattern has the added benefit that you are minimizing the attack surface of your code. If a user finds a security problem on the "running as user" side of your service it is a non-issue, while security problems in the privileged services could lead to privilege escalation. In fact, before Vista privileged services implementing a Windows message processing loop are vulnerable to a type of attack called Shatter attacks, which you should be aware of given what you are trying to do.
You want this running all the time, so you want a service.
You want something tracking each user, so you want an application which runs in the user session and communicates with the service (using named pipes or DCOM or whatever fits your requirements).
You don't need multiple instances of your service. From the description of your problem it looks like what you need is one service that can impersonate users and execute jobs on their behalf.
You can do this by implementing a COM object hosted in a service. Your client application (that the end user runs) will call CoCreateInstanceEx on your CLSID. This would cause new instance of your COM object to be created in your service. Then the application can use a method on one of your interfaces to pass the collected user credentials to the COM object (though I'd be wary of collecting credentials and instead see if I can pass the user token instead). The COM object which is running in the context of the service can then call LogonUser() to log on the user and impersonate it, so it can do whatever on her behalf (like finding the user local appdata folder :-)). Other answers havve good links to impersonating users using credentials or token.
If you feel comfortable with COM, I'd suggest you create your objects as multithreaded (living in the MTA), so that their execution is not serialized by COM. If not, the default single threaded model would be good enough for you.
The Visual Studio ATL wizard can generate the skeleton of a COM object living in a service. You can also read about implementing Windows Service with ATL here: http://msdn.microsoft.com/en-us/library/74y2334x(VS.80).aspx
If you don't know COM at all, you can use other communication channels to pass the credentials to your service.
In any case, once your service gets the credentials, all the work on behalf of the user will have to be executed on a background thread, so as to not block the application running as the user.