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.
Related
Scenario: I am working on website in which user login and do some tasks and logout. When user login in website I put a true value in database so other user is not logged in with the same username and password.
Problem: Above scenario was working fine. But I a face problem when unexpectedly PC was shutdown and that true value is there which I put in database on the first time when user login in my website. And the first user is unable to again logged in from same PC.
What I want: I need a mechanism in asp.net in which When unexpectedly PC was restarted / shutdown server automatically update my column in sql.
You can't use server code to monitor client machine behavior.
I suggest you re-design the database with a expiring time session, which will handle the login event when "true" value is on but user try to login again.
Another the way could be allowing users to "unlock" themselves, by email-reset token, or by secret password.
When user login in website I put a true value in database so other
user is not logged in with the same username and password.
It is not a good design, because internet is not reliable. You are very closed; instead of Boolean value in database, you want to store a token.
Solution
You need to redesign the system based on cookie (or you can also use bearer token).
When a user login, create a new token and store it in both database and cookie.
When a user request a page, validate submitted cookie with the one in database. If they are not same, ask the user to re-login again.
I need a mechanism in asp.net in which When unexpectedly PC was restarted / shutdown server automatically update my column in sql.
SignalR can help. On your website you have a HUB, that hub can detect when users connect or disconnect. Just map when disconnect is called and set that user in the database to false.
I agree with previous comments that it's a poor design. But SignalR can work around that for you.
http://www.asp.net/signalr
Consider the case of forms authentication with persistent cookies.
If the same user logged in using two different browsers or two different machines, when user logs out from one of the browser/machine, wouldn't still he be able to login from the other browser/machine?
Usually, how do web applications handle this case?
I have to agree with Srinivas for the most part. Here is my take on the subject
On Login create an HTTP Only cookie with a guid generated at login this will be your browser/computer key. Closing browser will remove cookie
Get user id
Persist in the pair in user table ex: user:a, key:12345
On subsequent requests authentication algorithm after user has been authenticated
Get the last used key in the db with current user id
Check that the cookie is present, if not then completely unauthenticate
Check that the cookie value is the same as that in the database, if not then completely unauthenticate
With this method any subsequent login will cause a required reauthentication & invalidate any other authentications. In effect forcing the user to use only 1 browser/computer
I usually do it this way : I have a session column in my user table(in database) When the user logs in I store the value Y in it.I change it to N when he logs out.Every time the user tries to log in, I check the value in the corresponding session column and if it is Y I tell the user that he is already logged in and if it is N then I allow the user to log in. But we have to be careful and set the value to N when the user logs out or closes the browser.
Forms Authentication with cookies (regardless of whether they are persistent or not) is browser session based (persistent cookie would of course work across multiple sessions of same browser (on same user account on same machine). So two browser sessions (or two different browsers or browser on two machines etc) would be treated as different scope as far forms authentication is concerned.
So user can make multiple login from different browser sessions and logout in one will not affect other. Its is up to web application whether to allow multiple concurrent logins for same user or not. For example, online banking sites would restrict to only one user session - so if user logs in from different session then earlier session is invalidated (i.e. user is logged out). One has to write custom implementation in ASP.NET to do so - typical implementation would make every user session entry into database (typically required for audit purposes anyway) - so whenever new entry is added, a check is made to see if there is any active session for same user and if yes then that session is marked inactive. Every request would check if current user session is active or not, if not then it would flag such message to user.
I've configured SQL Server to store session state (from here).
All I want to do is that when the user has logged into my application via browser A, I see that logged session when I visit my app from the browser B.
Right now that scenario doesn't work, I must log in one more time.
When browser B is opened (assuming it's a different browser altogether or a new instance of the same browser) a new session is created; therefore, what you see is expected behavior.
Also, I assume you mention this because you store in session some sort of key that indicates that the user has logged in successfully, correct?
If you want this behavior, you'd need to send some sort of authentication cookie with a long expiration date, you'd then read the cookie on the login page and consider the user as successfully authenticated, but keep in mind that this is a potential security risk.
Let suppose, I am building an asp.net website which has login scenario in it. I want to provide a certain functionality to the website that if the user is already login on computer 1 and now try to login on computer 2, so he will be allowed to remain login on computer 2, while automatically logout him from computer 1.
I also know that http is a stateless medium, so whenever user interact with computer 1 and try to interact with the page, it will get noticed at that time.
You need to store the additional data (the computer currently 'logged in') in the database, or application state. Then when you process the authentication request - check to see if the machine you stored matches the one requesting authentication - if it does not, you would force the user to log-in and store the new computer (ip address) in the database/application state.
In case Tony's suggestion does not fulfill your purpose, You need to generate a hash comprising of "UserLoginName" + "HOST_NAME" +"TIME" (or any combination you like) and store that hash in your Database against that loginName and also send that hash to the user in a Cookie.
On subsequent request you can check through a handler or module if that specific cookie is submitted and contains the value matching your database, if it matches then the user is coming from the same machine and no need to update anything , if not user is coming from some other machine either the cookie shall not be there or would be containing some other hash value so you should send him to Login page again and upon login just recreate the hash and update it in your database against his login.
Hope this shall work.
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.