I am using the provided ASP.NET SQL Membership & Role providers in my application.
How can I prevent that the same user does login from different workstations using the same credentials? I can imagine to use the IP address for this but I dont really know where to start from...
Also what about users behind the same router? Is there a way to prevent them access from different client PC's?
IP would not be a very good way as all users behind a typical company LAN would appear to you as connecting from the same IP. A workaround is to logout the user that is logged in with the same credential thus keeping only the latest one logged on. This can be achieved by keeping the logged in user's ID or name in Application or DB. As soon as a new user session is started, check if the user is present in Application/DB. If so, mark it dirty. In the pages, check the presence of UserID/Name in the Application and if the user is marked as dirty, invoke a logout. This can be implemented in a BasePage that all the pages within the site/app inherit from.
Perhaps you can store whatever you are using to uniquely identify the user like a UserId in ApplicationState and check to see if that value is not null. You add their UserId value to ApplicationState at the start of SessionState and then at the end of SessionState remove that value from ApplicationState.
ApplicationState is global to the web application meaning it is accesible to all users and sessions while SessionState is limited in scope to a single user and session.
Related
I am building a multi tenant MVC4 web application. I distinguish the tenant based on the url alias (customername.webapp.net). I have a database that stores the customer id which I can lookup using the customername.
Obviously I need this customer identification during the entire session that a user from that customer is using my webapp.
Is it acceptable to store this unique identifier in the session? Or are there better design choices for this kind of "session data"?
I'd rather store this information inside the UserData portion of the forms authentication cookie (if you are using Forms Authenticatoin) or simply add it as a claim if you are using claims based authentication. When the user logs-in you would extract the tenant name from the current request, query your database in order to obtain the tenant id and then persist this id. If you store the id in the UserData portion of the Forms Authentication cookie you could write a custom [Authorize] attribute which will read the FormsAuthenticationTicket, decrypt it, get the tenant id from the UserData portion and then build a custom principal. This way you will have it available everywhere in your application. If you use claims based authentication, you would simply add it as a new claim.
I wouldn't use Session at all inside my application.
Please don't be misguided by the answer. It is dangerous to use cookie.
Session in this case would be the valid option, not cookies. If you store your tenantId inside your cookie, and your application establishes database connection based on your cookie, then after you login as a user, you can tamper and change the cookie and now your application will make connection to another database thereby compromising security. Even if your cookie is encrypted, it's not 100% reliable.
Session in this case would be the reliable server information that keeps track of which tenant database should be connected to. Although session can be a performance drop compared to cookie, in this case you have no other good options. You are designing a multitenancy application and that's just something you have to sacrifice.
Yes, you may still able to use cookie if you REALLY want to. You just have to keep checking if the user is connected to the right database somehow, which to me is more of a performance drop than using session.
Don't hate session just because alot of people abuse it or hate it. You just have to use it in the right manner.
Bottom line is, if you are using any info for security purposes, don't use cookie.
How can I prevent a single user from logging in to my asp.net website from more than one computer at the same time?
I have tried using the application server side state managenment but it is not work properly.
1) If you are Using Coookies to Track Users,
When a user logs in you write a unique guid to the database and store it in their authentication cookie, then every page request you check to see if they (GUIDs) are identical, and if not you log them off.
2) if not using cookies, Store the UserName, GUID in Application Cache, and user Session variable. Compare User Session to Aplpication Cache to see if he is already logged in.
I am trying to find a solution to control the number of logins on asp.net application.
I need to install the application in the client server, and set the number of licences. e.g. only 10 users are allowed to access the app.
Every time someone tries to login I need to check how many user are logged in, compare with the total allowed then authorize that user to proceed.
I tried with Certificate, but I couldn't see where to match the number of logged in users with the max number of allowed user.
Also I would like to use the IP address as identifier, then if I open 3 browser windows, it count only one user logged.
Basically this web application will be sold by licences. We need to control the logins per computer, and not per user, and block logins if the limit of logins are reached.
Please forgive me, if i am not clear with the description.
Thanks for any help.
I would use the SessionID in the Session object as the key, I'd store that along with the UserID for the logged in user in a database or some kind of backing store. I'd use Session_End in the global.asax to remove the records above for any session expiring and also remove them in any logout function. You should find it fairly simple to count the number of active sessions you have and confirm that it's not the same user logging in again, if that's allowed.
What I would do is use the global.asax file and increment a counter in session_start and decrement on session_end.
Since the session is stored in a cookie, several sessions on the same computer only create one session.
Here is a good refrence for the global.asax file:
http://aspalliance.com/1114_Understanding_the_Globalasax_file.3
I would use the Membership.GetNumberOfUsersOnline method, if you are using the Membership API, to determine the number of active users.
I believe this number only counts the number of users you have authenticated so it is safe to use in your scenario.
I am using
FormsAuthentication.SetAuthCookie("username", true );
so that a helpdesk person could impersonate another person's ans go in and see what the account looks like. I as wondering if there is a way my code can determine that this session is running through impersonation (so that I can block a couple of pages and flash a sign saying "You are impersonating this user: username)?
The best thing to do here is make sure the helpdesk users have to be logged in as themselves before they go to the page that allows them to impersonate another user.
At that point, either save a session variable or send a second cookie down to the browser that identifies who they really are and any other info you need to keep up with. I prefer storing this in session variables because it is more secure and you remain in control of the information on the server.
The rest of your code would work mostly like it does now responding as if the user really were the one they impersonate, but any code that needs to test for impersonation can read the session or alt cookie to know if they are impersonating or not.
very simple question:
I have admin site in my web project. So, how can I make it safe?
What I have until now:
Database handled user with userID and userlevel
on the pageload of the admin master page (which includes all admin sites) there is a clause to check if userID is okay (get the user from database) and if userlevel is right
If Not, redirect to Default.aspx with normal master page
if yes, go trought
How safe is it really?
Edit:
The userID is saved in a session on the server.
There is no way to save the login (no cookies).
The user must login to get the userID in the session
The login is saved in a database table user_log with username, password, ip, loginsucceeded and userID
The basic idea looks ok. It all comes down to how you are getting that UserID to make the checks against. If the userID is being passed as a querystring, then that is very bad. If it is stored in a session via sometype of pre authorization then it is better. If you are using SSL, IP checking, etc it will improve your level of security.
The main thing is HOW you are getting the userID to verify against. That is where the exploit will occur. Secure that process and you should be ok with your setup.
Edit: Based on your update this looks ok but it also depends on how secure you really need this to be. How secure is your sign in page? Are you using SSL? Any worries about session highjacking? Why not store an IP with the userID and verify the request IP against the stored IP when doing the UserID fetch from the session?
There are so many security solutions out there. You need to decide how far you need to safely go to ensure the level of security that is necessary for your particular application.
We use integrated windows authentication.
In IIS manager, click the "Directory Security" tab
Uncheck "Anonymous Access"
Check "Integrated Windows Authentication"
This lets you administer who has rights to your admin site by modifying domain accounts instead of using a roll-your-own solution. You can still get the logged-in user's credentials via the Environment class, which can be used to associate any web-specific properties for each user that you want to store in your database. This also has the advantage of automatically handling timeouts, relogin requirement if browser was closed, etc.
Your solution looks almost fine, though it sounds as though you're adding individual user accounts to the SQL server instead of handling everything through the ASP.NET service account login. I'd avoid adding individual user accounts into your database. In ASP.NET, unless you're jumping through some useless hoops, the ASP.NET service account is what is authenticated for DB connectivity, not the user that's logged into the site.