The basic setup is classic - you're creating a Windows Forms application that connects to a DB and does all kinds of enterprise-y stuff. Naturally, such an application will have many users with different access rights in the DB, and each with their own login name and password.
So how do you implement this? One way is to create a DB login for every application user, but that's a pretty serious thing to do, which even requires admin rights on the DB server, etc. If the DB server hosts several applications, the admins are quite likely not to be happy with this.
In the web world typically one creates his own "Users" table which contains all the necessary info, and uses one fixed DB login for all interaction. That is all nice for a web app, but a windows forms can't hide this master login information, negating security altogether. (It can try to hide, but all such attempts are easily broken with a bit of effort).
So... is there some middle way? Perhaps logging in with a fixed login, and then elevating priviledges from a special stored procedure which checks the username and password?
Added: OK, so integrated authentication and windows groups seem to be a fair choice in most situations, so I accepted the relevant answer. Still, if anyone can come up with a non-integrated authentication solution, they'll get an upvote from me.
For WinForms use Windows groups. No passwords are needed because the credentials are inferred from the Windows login using your application.
This is best practice
Basically:
The user belongs to a group (assumes single domain)
Group is a login in the SQL Instance
SQL login maps to a database user
DB User belongs to a DB role
Role has object permissions
It's worth reading up first before having someone try to capture all the information here
Edit:
If you have a workgroup, you can still do it by setting up sqlbox\bob, sqlbox\hans etc in a sqlbox local group.
When someone tries to connect (say bob on his PC) windows will ask them for their details. As long as bob knows his SQLbox account detailsm he can connect.
But then, I've not tried this in a workgroup setting...
In addition to using Windows Domain/AD Groups (put the AD groups in appropriate roles you create in SQL Server, so all account maintenance moves to AD), be sure to use the Application Name in your connection string - this allows you to see which applications are performing operations in the profiler etc.
Because when everyone is logging on as themselves from different applications - windows and web, it helps to know that it's actions taking place through an application and not just any user's ad hoc query through ODBC and Excel, say (if you allow users access to certain views for data export or report writing).
Can't you use Active Directory Groups to make the management of the db connections easier?
From MSDN...
The name can be a Windows user name or a Windows group name, of the form DOMAIN\Name.
That way you may have a few groups, read-only, editor, manager, admin etc. It's how I have achieved similar things in that past with Click-Once apps.
It really is the best choice for what you are doing.
I am assuming this is an existing app? If it was new I would otherwise say to go client server with web-services or similar.
PK :-)
With regards to wanting to hide your authentication and use a single application login with WinForms, if the login has very little privilege - select only on views and execute only on stored procedures, anyone who manages to reverse engineer your encryption of the login information in your application will only be able to perform the same functions they could perform in your application. If you absolutely have to raise the level on the security, you could authenticate each stored proc against your users table (poassing user and hash to each SP). Also, rotate the central application login on a regular basis.
All this is a lot more difficult than using integrated authentication and implementing AD platform in your environment. So you're effectively writing your own directory and authentication instead of using one off the shelf.
In addition to gbn's update about workgroup versus domain, you can run the application with RUNAS /NETONLY /USER:SERVER\USER with user credentials on the domain or server which your machine is not a member of. At the point that the application makes the connection to the database, the remote credentials will be authenticated and used. I have an application which actually checks to see how it was run and if it not run with a particular switch, it prompts for username and password and then re-runs itself using the Windows API using a function equivalent to RUNAS /NETONLY /USER:DOMAIN\USER. This is because our workstations are not currently on the domain (or on a domain with a trust relationship) of the SQL Server. In this case, you could still manage the security in local groups on the SQL Server or groups on the domain of the SQL Server. You would basically just lose out on the automated authentication token.
Related
I have 3 machines, one of them is acting like a server that contains the database and tables. However when I try to connect over the Named Pipes protocol, I need to add a domain account to each machine.
What I want to do is to access the database remotely using the 2 other machines without adding any user; I'm using Windows authentication.
When you use Windows authentication, you need to have the same Windows account on both the machine making the request, and the server.
To do what you are trying to do, you would need to use SQL Server authentication or user impersonation. Personally, I find user impersonation to leave too many potential security holes, so I recommend SQL Server authentication.
Very top level question so very top level answer:
Extend and manage permissions by Active Directory groups. Place individual user's accounts into the active directory groups. You are now managing permissions from an AD perspective and not by a individual machine perspective. ie user mgmt happens in one place instead of distro.
This way you are not constantly adding/removing users to multiple machines. They are just placed in the group and have access to X number of servers due to permission inheritance.
It also saves you from hard coding sql account credentials into distributable applications. Not a huge concern if this was a web application but think what would happen if you had the need to cycle your sql user password and you had your wpf application installed on X number of machines...becomes a management/release nightmare
I have a very basic question and want to know how other experts do this
I have an application with some 100s of users. I have been using SQL LOGINS to authenticate these users. These users have password policy enforced. and I face difficulty when any user's password is expired i.e. i have to reset it from SSMS myself. It sometimes becomes a difficult job along with other tasks that i do.
I was told by some experts that it is a good practice to create my own user table and have all the user details in that table. I have created a user table with following columns.
User Id
User Name
Password
PasswordCreationDate
PasswordExpiryDate
PasswordActive
One simple question. How do my users connect to the database . Offcourse i would need a connection string from the application. That connection string would require a user name and a password isn't it? and I can not get the information from the user table until and unless i am connected to the database.
Another problem, how do i keep track of last 5 password. The policy says that the user can not use any of the last 5 already used passwords.
All this can be avoid if I can get a solution of notifying my users that their Password is due to expire in 'n' days and they must change it before it expires.
What do the other developers do when authenticating their users. Please Guide Me
If you keep your user's login credentials in the database, then for access to sql server itself you may only need one login for the entire app. This login would have full access to your database, because it would be up to your application to enforce access rights.
If you go this route, you need to be aware of two things:
There is still a security concern for larger applications that need to give ad hoc reporting capabilities to users through tools such as Reporting Services, Crystal Reports, Infomaker, etc. In this case, users can use these reporting tools to gain read access to areas of the database they should not be able to see.
If you store your own credential information for your users, you need to make sure you do it properly. That means no plain text passwords. You need a cryptographically secure password hash (not md5!) and a per-user salt. If that's greek to you, best to leave this alone.
Another option open to you is to use Active Directory/Windows Authentication for your database. The trick here is that you still have to set up access rights for all your users. However, you can use Active Directory groups for this to reduce the number of logins you need to create, and it will at least prevent you from needing to reset Sql Server logins by hand, because users will log in with their Active Directory account.
A pretty common scenario amongst web applications is to use one username/password (so only one sql login, typically some kind of dedicated login with minimal rights for the application). This way, connection pooling can be used. This is of course a backend account, configured in the web.config and not visible to the end-users.
The users are maintained as a type of data within the application. Asp.net comes with a solution that is called Membership. User authentication is done against the Membership provider and several classes give you programmataic support for authentication, roles, etc. You can use AD as a provider for example, or forms authentication. Or you can write your own.
Since you are now using a dedicated sql login for each user, you need to be aware that this approach moves data access security to the application level. So this might not always suit your needs.
Ideally you'd use existing Active Directory infrastructure to handle your authentication/authorisation of individual users, and you could then have end-users' credentials passed via the web server to your SQL server (You'd probably need to look into handling the Kerberos "double-hop issue" to effect this).
But failing this, it's easy to set up so that the application it self has a SQL login to access the database in order to retrieve user level authentication information. One-way hashes on user passwords would ensure that even if the app's password is read from connection string, user passwords can't be obtained.
Or somewhere in between those two solutions, where the application has a service account within AD, which has access to the SQL database, in order to retrieve the user account info from within the DB.
Either way, if AD is available you can secure further with Kerberos Service Point Names to ensure database access from only your expected end-point (ie the ASP.NET server).
I am wondering if i need to add any other kind of security on this asp.net application - web forms (available only on network domain and through VPN connection)?
Application Environment: Asp.net 4.0, Vb.net, Oracle 10g, Web Services, Window server 2003 or 2008, Hosted on domain
User Authentication Mode: Window (Not using asp.net membership)
Authentication Scenario:
Application is accessible via intranet site and system authenticates user with his system user name. On the default page system will first get the current user name (HttpContext.Current.User.Identity.Name) and then match it in the user table (oracle DB), if it is matched then store procedure will return all the access permissions (menu details) relevant to this user group. There is a user group and permission table in the oracle DB.
In the store procedure, system will also check the user permissions before any DML transaction.
Main security concern
Major: restrict people to access the information depends on their permissions. Normal user shouldn’t get access to other’s data.
Minor: We don’t want anyone to get into our system outside office network.
As Joachim says, this arrangement only supports Windows systems running on the local network. Shifting to basic authentication will allow more clients to connect but exposes the passwords on the network (effectively in clear text) without HTTPS. Forms authentication is similar.
Without server authentication, users could be redirected to a similar server without their knowledge or suffer a main-in-the-middle attack. HTTPS gives you this with the server certificate. This may not be a concern on a local network but users' hosts (in c:\windows\system32\drivers\etc) files are often vulnerable.
Without encryption, any user can sniff the information sent back and forward over the network assuming they are on the same subnet. This may be an acceptable risk for most applications but not if the information is sensitive, e.g. contains sensitive or personal information.
Consider replay attacks (see How do I prevent replay attacks? for an example) if people are performing important operations like approvals.
Consider auditing access to the database, particularly the user group and permission tables. Someone could add themselves or move them into a group, perform an operation then remove themselves. Check your pages for SQL injection and similar attacks which could accomplish this.
In summary, how likely are people to compromise or interfere with the system and how much are you willing to invest to protect it? Assuming the server can handle the load, HTTPS is a hard to go past as a first step.
Unsure what kind of ASP.Net technology you are using (MVC/Razor/Web Forms).
If you are using Web Forms, then you can immediately take advantage of ASP.NET Login Controls like LoginView Control. They work with ASP.Net Forms Authentication (with or without using ASP.net Membership). You can also take advantage of Roles.
Your intranet server should be "protected" if it's not exposed in your network publicly (in any way). Of course that's a bold statement that depends entirely on your network implementation - e.g. subnetting, internal net/no nat/route/no port forwarding, no dns, etc. This makes VPN as your only point of exposure from the outside, then you must enforce proper security policies for your VPN infrastructure - e.g. one-time passwords, client inspection, etc.
Update:
If you are using Active Directory, you can create users/groups in AD to provide access accordingly (e.g. Finance AD group can only access "finance" folder). I haven't kept abreast with browser support for NTLM outside of Internet Explorer however.
You did mention user data is in an Oracle db however(?). I'm not familiar with solutions that allow no login screen access (to network resources) using a db/Oracle.....
Also, that would mean one-time passwords for VPN access may not be available. Look into token based VPNs so users can still use their AD credentials but need a new token each time - this will help mitigate the "passwords in yellow sticky notes" (because you can have tighter control over tokens).
I am using a C# application and connection to database using sql server 2008 using windows authentication. I have created several users for the database but i am unable to understand how to use them on my application level. My goal is to install this application on any pc and make the database un-accessible by the users if he tries installing sql management studio.
Can somebody please explain or give me any good references to understand what i want to do ?
IF you want to make sure the users can't access the DB without your app you have several options:
implement "virtual users"
This would mean you implement your own user management and don't create real DB users for your app users but only "virtual users" in your own structure... your app would use a general app user for DB access which is unknown to your users... since the app users aren't reall DB users they can't access the DB directly with their users/pw.
implement a "special password scheme"
This would mean you create real users... but only your app can create an app user... when the user is created or changes his password you don't set the users DB password to that but use some calculation (for example a hash) to create a different password and set that on the DB level... your app knows the calculation so when the user logs in your app does the calculation and uses the result to log into the DB... this way the real DB user can't log into the DB directly because the password they know (which works only when used with your app) is not the one the DB knows...
BEWARE that none of the above is 100% secure since your .NET app can always be decompiled/reverse engineered etc. - although the above is certainly enough to block "normal users" from accessing the DB directly...
Many desktop applications use SQL tables to manage their users permissions and roles. In fact they restrict access to some parts of application in their application code. It means they need a constant connection string to SQL server with maximum permissions.
My target is C# 2010, Sql Server 2005 or 2008.
What if with any reason someone find that connection string ?(Network tracing, Software hacking, Fired Employee or ...), He can change everything with just Managemenst Studio and you can't understand which client did it. If you want to change connectionstring. You must do it in many clients and in a bad design you need to recompile application.
So i want to know is it good idea to use real SQL login instead of username and password in tables ? make connection string for each user by SQL Logins ?
In this way there is no afraid to loose connection string. Also in SQL codes you can use GetUser() function to indicate which user really runed the query ?
But maybe the managing permission is difficult with this way because there is no simple table to manage permissions and users.
In one long sentence. I want to know What is the best way for authenticating desktop application users in a way that managing permission can be done and also sql server can log user activity ?
Whenever possible, use Windows Authentication.
Define Roles. Add Groups to Roles. Add Users to Groups (as per usual Windows way of managing file system permissions).
Choosing an Authentication Mode
See: Application Roles
You can encrypt sensitive sections of your app.config file. Last time I checked, you have to go through some hoops, but it's not that difficult to set up.
See for example this question
For best security, you need one dedicated database account per user; each account should only have the privilegeds necessary for the tasks that the corresponding user may perform. Normally you grant privileges to roles (e.g. "clerk", "manager", "supervisor") and grant those roles to the users. Obviously, it requires some work to identify which privileges each role needs. In many cases, it might be necessary to not allow direct access to some tables, but only to database views that hide some parts that should not be visible to that role, or to stored procedures that do some additional checks and make sure that each transaction is processed as a whole.