How Can I Secure my ConnectionString in WinForm Application?
You can't. Although you can encrypt the connection string in the app.config file, the application needs to be able to decrypt it and it is, therefore, always possible to retrieve the unencrypted connection string, especially with a managed application (perhaps not for your typical end user, but any skilled developer, or hacker can do this, and even end users can figure this out after a little bit of googling).
The solution to this is to not lean on security by obscurity. Use Windows Integrated Security when connecting to the database using the Windows user account and give the user the minimum amount of rights in the database.
Often though that is still not enough, because it is very hard to secure the database enough when end users are directly connected to the database (often because you need row-level security). For this to work you need to deny access to tables and views and completely fall back to stored procedures.
A better approach, however, is to prevent the desktop application from communicating directly with the database. Instead, use a web service as intermediate layer. In that case you have full control over the security and you can store the connection string securely on the (web) server.
Related
I am working on a JavaEE project with WildFly, Hibernate (JPA), C3P0 and a MS SQL Server database.
The database is a legacy database with more than a thousand Database Objects like Stored Procedures, Functions, Views, Triggers and so on. All these database Objects have fine grained Permissions set on User Role level.
Now I need to access this database with a JavaEE Web Application. My Problem is, that the usual JPA configuration let me set only one Username/Password for the Database in the configuration file. I can not find any way to configure the JPA layer so that will access the DB with the Enduser's Login.
I ended up to create one EntityManagerFactory per User by calling
EntityManagerFactory entityManagerFactory =
Persistence.createEntityManagerFactory(properties_with_credentials_here)
once per user.
The problem with this approach is, that this will basically instantiate the whole JPA layer per User and eat up way too much memory. I am not using any sort of Cache layer, of course. The memory is used just for the Entities meta information (which is a lot).
Now my original question: Is there any 'standard' way in JavaEE (JPA) to access the database layer with the Enduser's Login and Password?
I can not believe that I am the first person to encounter this situation. It seems to me, that 'impersonation' is quite normal in .net Web Applications. So there must be way to do this in Java, i guess.
Any comments or hints or new approaches are highly welcome.
The 'standard' way in JavaEE is to have an application user for accessing the database and achieve user-based access-rights through roles in your application.
If you need to rely on existing database user, your only chance is to establish a connection per user or per request. The entity manager would then indeed consume some memory as it's designed to be your application's persistence context (and thus some sort of cache).
Maybe you can have some trade-off here by accessing those parts which really have to be user-based by plain JDBC and potential execution of database procedures and others by some application user with extended rights which ensures the necessary user restrictions programmatically.
Microsoft recommends using Windows authentication when connecting a Windows application to an SQL server database.
http://msdn.microsoft.com/en-us/library/89211k9b.aspx
I understand this to mean that the database must have a user with enough permissions to manipulate data and that user links to the currently logged in Windows user. If this is true, how do I prevent the user from bypassing the application and simply modifying data directly in the database?
It seems like I am stuck between using Windows Authentication and potentially allowing users to modify data directly in the database, or attempting to hide the connection string password somewhere so only the app can modify this data.
If you're that concerned about it, you can implement a logon trigger on the server that for certain people (e.g. members of a certain Windows group), they can't log in unless the application name has a certain value. Note that this is weak security since it's pretty easy to set the application name (even in SSMS). It can/will slow down the logon process, though. So keep that in mind if that's a concern for you.
Alternatively, you can have your application authenticate to and interact with an application server, after which the application server connects to and interacts with the database. The application server can run as a service account, to which you'd grant the permissions you need. This way, the end users' accounts aren't in the database to do raw DML against the db.
But I agree with the other answer here: stored procedures are the classic answer to this question.
It is possible to create stored procedures / views etc and only allow the user permission on those. This prevents the user from accessing the database structure directly, and you maintain control over what the user can do (via creating the functionality in the stored procedures / views). If using windows credentials, I think that this would be the best solution.
This site explains how to grant there permission on stored procedures.
http://msdn.microsoft.com/en-us/library/ms345484.aspx
Here is the list of options, for posterity:
Windows authentication only
Pros: simple, No secret to hide.
Cons: user can easily modify data bypassing your app
Password in connection string
Pros: simple, prevents user meddling in your db's.
Cons: have to hide a password yourself, which is always the worst option.
Sprocs access
Create sprocs to access your data, grant access only to those sprocs. No one but the dbo can alter tables.
Pros: Tightest control over what both the user and the application can do to the data
Cons: Higher coupling of database and application; more expensive than the first 2 options.
Proxy
Create a second executable, whether a web or a windows service, with which your GUI application communicates. The 2nd executable can run with different, securely hidden credentials (IIS, Windows Services).
Pros: Decoupled database and executable, securely hidden secrets.
Cons: By far the most expensive solution.
I have a rich client program installed on users PCs where I want to start storing some user created data on SQL Azure/SQL Server. The potential anonymous-to-me users would key in their name, email account and a password which would get stored on SQL Azure/SQL Server. Then they would start generating their own data. I'm anticipating volumes of maybe 1000 users.
There are times when those users would like to run their own queries against their own data but, obviously, I must ensure that they can never view other users data.
I'm thinking the best way to ensure security of data is for each user to be issued their own SQL Azure account and password. I will setup a SQL Azure user and long password, known only to me, which only has permissions to execute several stored procedures with appropriate parameters being passed to those SPs which will create the SQL Server accounts, logins and add the users to a role which I have created.
Obviously someone running debugging tools could figure out the user name and password but I'm thinking this isn't a big deal. If all that particular SQL Azure account can do is execute a few SPs so what if a malicious individual starts doing that. I will only allow a very limited amount of data to be uploaded before I require payment.
The users can only insert records using stored procedures which use the following:
SELECT #uName=SYSTEM_USER
and only select appropriate parent records. All stored procedures which users can execute would have the above as required to ensure they can only work with their own records.
All views will have embedded with them WHERE clauses such as
WHERE tbLoginName = SYSTEM_USER.
I'm new to SQL Server so I may be missing some fundamental concepts so I'd appreciate any and all comments.
The issue is, as pointed out on http://msdn.microsoft.com/en-us/library/ms189751.aspx:
In SQL Azure, only the server-level principal login (created by the provisioning process) or members of the loginmanager database role in the master database can create new logins.
Those accounts are also capable of alter and drop logins. So if you embed those accounts in the client application, you’re essentially granting every user permission to alter/drop other users accounts. While an average user won’t do that, a hacker will. So you cannot let a client application manage SQL Azure logins, unless only trusted users (such as your IT administrator) are permitted to use the app.
Best Regards,
Ming Xu.
I would like to point out a potential issue in the approach you mentioned: Your master SQL Azure account need to have privilege to create new accounts and grant them access to particular tables. This means your master account itself need to also have access to all those tables. If you store the master account on the client side, a clever user will get access to all users data.
From my experience, connecting to a database directly from a client side application will almost always make your solution less secure. You can do that for testing purposes, but in a real world solution, I would like to suggest you to use a service. You can host the service in Windows Azure. Then the service will access the database, and client application can only access the service. In this way, you can authenticate clients using any mechanisms you like, such as ASP.NET membership.
Best Regards,
Ming Xu.
You are essentially creating a physical two-tier database connection, allowing a client application to connect directly to the database. This is a problem in many ways, including security and performance. From a security standpoint, not controlling from where your customers will connect, you will need to keep your firewall rule wide open for anyone in the world to try to hack every customer uid/pwd. And instead of having only 1 user id to play with, hackers will have up to 1,000...
The second issue is performance. You applications will be unable to leverage connection pooling, creating undue stress on your database server and possibly hitting throttling issues at some point. Using a web service, with ASP.NET membership to manage logins, and using a service account (i.e. the same uid/pwd) to get data will ensure you will leverage connection pooling correctly if you keep the connection string the same for all your requests.
With a web service layer you also have a whole slew of new options at your fingertips that a two-tier architecture can't offer. This includes centralizing your business and data access logic, adding caching for improved performance, adding auditing in a centralized location, allowing to make updates to parts of your applications without redeploying anything at your customer locations and so much more...
In the cloud, you are much better off leveraging web services.
My 2 cents.
I want to distribute an SQL 2008 database to a client and set it up so that the only way to access the data in it is through my application. Can I use Truecrypt for that? Can you think of any other solution?
No, is not possible. This is asked repeatedly and the answer is the same: protecting the data so that is only usable from one application is DRM and SQL Server does not do DRM. There is no cryptographic/encryption or authorization/permission mechanism you can set in place to prevent a legitimate administrator from seeing and using the data as it sees fit, including granting other applications permission to use your application data.
At worst you can encrypt all the data in the client and store only the encrypted blobs, thus rendering it unusable to any other application. This approach looses any advantage a relational database offers (data cannot be searched, queried, indexed, foreign relations and constraints cannot be enforced etc) rendering the SQL Server absolutely useless for your application. Besides, even in this case, short of using a hardware module, the data is not trully protected since the application cannot embed any encryption key in a secret fashion (any key embeded in the app, no matter how obfuscated it is, can be retrieved, always) and relying on the user to provide a secret password means the user can simply decrypt the data.
If you want to use a DRM scheme (which you are actually asking for), use a DRM product.
I've taken a quick look at Truecrypt and it doesn't look like the tool for what you're trying to do.
You should look at SQL Server Logins, Users and Roles. How you use these will depend on how you setup your database connection. If you can provide more information about how you are connecting I can try and help further.
We are building an hosted application that uses MS SQL Server Analysis Services 2005 for some of the reporting, specifically OLAP cube browsing. Since it is designed to be used by very large global organizations, security is important.
It seems that Microsoft's preferred client tool for browsing OLAP cubes is Excel 2007 and the whole infrastructure is geared around Windows Integrated Authentication. We, however, are trying to build an internet-facing web application and do not want to create Windows Accounts for every user.
It also seems that there are not many nice AJAXy web-based OLAP cube browsing tools (fast, drag-and-drop for dimensions, support for actions, cross-browser etc.) As an aside, we're currently using Dundas OLAP Grid but have also considered RadarCube and other more expensive commercial solutions and are still thinking of taking on CellSetGrid and developing it further - if you know of any other cheap/open solutions please let me know!
We are therefore planning on providing two modes of access to the cube data:
Through our own Web Application using one of these 3rd party Web-based OLAP browsing tools.
Direct access from Excel over HTTPS via the msmdpump.dll data pump, for when the web version is too slow/clunky or user needs more powerful analysis.
For the web app access, the connection to the SSAS data source happens from the web server so we can happily pass a CustomData item on the Connection String which indicates which user is connecting. Since we potentially have too many combinations of rights to create individual SSAS roles for, we have implemented dynamic dimension security that uses a "Cube Users" dimension in conjunction with the CustomData item from the connection string and limits the Allowed Set of various other dimension members accordingly (via other Many-to-Many dinemsion relationships with Measure Groups that contain the 'rights mapping')
See Mosha on Dimension Security:
http://www.sqljunkies.com/WebLog/mosha/archive/2004/12/16/5605.aspx
This all seems to work fine so far.
For the 'direct connection' from Excel, we set up the data pump for HTTP access
(see the MS Technet article) but have enabled anonymous access, relying again on the Connection String to control access since we don't have windows accounts.
However, in this case, the connection string is controlled by the user (we push a .odc file from the web app, but a curious user could view & change it), so we cannot rely on users to be good and keep the CustomData=grunt#corp.org from changing to CustomData=superuser#corp.org. As it turns out, this also causes the same problem with Roles, since these are also specified on the connection string if you are not using Windows Integrated Authentication.
The question therefore boils down to this: is there a way of getting basic authentication in IIS working without windows accounts in such a way that it can be used with the SSAS data pump to let SSAS know which user is connecting so that dynamic dimension security can be used successfully?
(This is my first q on StackOverflow and probably the most complicated question I've ever asked: let me know where I haven't explained myself very well and I'll attempt to clarify)
Basic authentication will work with local user accounts (non-domain) and even support passthrough authentication if the local accounts exist on different machines, however you should force SSL as basic authentication sends passwords in plaintext.
You can use non-windows accounts with basic authentication in IIS with add-on such as http://www.codeplex.com/CustomBasicAuth, but SSAS will still need to know who that user is and as far as I know SSAS uses only Windows authentication.
For a (relatively) cheap thin client front-end for SSAS look at RSInteract. For bonus points it will also consume SSRS reports and report models.
Any attempt to use dimension security will require SSAS to be aware of the user and have their access rights available to it. I don't see any way to get around maintaining user permissions.