I've got an existing site I'm taking over, and right now it stores, in a session variable, the id of the currently logged in user (if logged in at all -- otherwise I'm sure it is empty string or null or something).
The client now wants, after someone is logged in, to "keep" them logged in on that computer for an indefinite amount of time.
ASP.net Sessions have a maximum idle time of 1 day, I believe. The website isn't written all that well in the Flash portion (whole front end is flash) and the flash will process a login, then, as long as the flash isn't reloaded, assume that the user is still "logged in".
I think my solution is to ALSO store a client side cookie with some GUID value and hold in the database the associated user id...sort of like a session that never expires. So, when the page is loaded, I can check my cookie, use that to select the userid out of the database, and if we find one, then set the session value that says user 23 is logged in.
Does anyone see any issues with this perspective? Would you recommend something different? I really don't want to refactor a bunch of the existing code, but just slip this in on top...
PS -- security is not really a concern. The only reason they have people log in is so we can track orders by a person, but no money changes hands through this website. There is also no personal information that a user can view or edit, either.
This is how I do it. I actually have a cookie that holds their login and password, this way I can automatically log them in should they not be logged in. I expire the cookie after a couple of days of inactivity. The downside is that everyone forgets their password because the only time they really have to enter their password is when they come back from extended time-off.
This is for an internal application, with the same customer demands that you have and this works ... and makes the customer happy.
One thing we may end up doing is just using Windows authenication, might actually work better in this circumstance.
That's the way I do it, but the problem with it (at least I think its a problem) is that when you store the username and password in a cookie there is not any encrypting when you add the cookie. If you look at the cookies in your browser the username and password are displayed there plain as day. Is it possible to get some kind of encrypting on the cookies you store? Or how would you handle this?
Check this blog posting out http://timmaxey.net/archive/2009/03/06/asp.net-cookie-auto-log-in.aspx basically you needs to save the cookie with a guid a series, and a token, the token, in my case, changes all the time, the series is something that is generated based on something, like the guid and id combo or whatever, then the guid is always stored with the user. There is a cookie table to stored this info etc... pretty secure, not 100%, but pretty good... Tim Maxey
I recommend using the Enterprise Library Crypto App Block to store an encrypted cookie which is nothing more than a GUID. Get the GUID, and use a session table in the database to track user info.
At the session start event, get the user info and cache it.
Using the session object is not recommend for user info because it won't work on a web farm, unless you use a database for session state.
You're basically rolling your own session state at that point, and I'm fine with that. However, I would not go the route of storing the username/password in a cookie (even if encrypted). There's no way to expire that from the server-side. You can always remove your row in the table to force a user to log in again, but if they hold the username/password they hold the keys to the kingdom.
Related
We have a log-in form in ASP.Net Webforms. and when user logs in we save the user id to session state.
Session["CurrentUserId"] = user.Id;
So this is how we know a user is logged in.
if(Session["CurrentUserId"] == null) Redirect("Login.aspx");
This is all we use Session for. I am storing session in DynamoDB because we have many load balanced servers. But sometimes DynamoDB gets overloaded or gives errors. So I trying to get rid of session state to avoid these errors and to simplify a login process.
So what alternatives are there? How do modern websites log people in and remember they are logged in, and timeout after x minutes?
Is there a way to use a secure cookie to just do it? And how would you expire it if user doesnt do anything for 20 minutes? It has to work over a collection of web servers.
Storing user ID in session is not necessarily bad but has to be combined with other things in order to secure the site against things like session fixation attack and CSRF (also known as "session riding"). It is also problematic in a web farm if you are using in-proc session state.
In ASP.NET web forms, the standard way to authenticate is to use forms authentication, which places an encrypted cookie ("authentication ticket") on the browser. You may also want to put the user ID somewhere in session and compare it to the authentication ticket in order to ensure they match.
if you using the standard FBA login providers?
You can get user logon ID with this:
Membership.GetUser.ProviderUserKey
And you can get user email with this:
Membership.GetUser.Email
So, the user logon id can be fetched with above.
As for session() being a bottle neck?
Well, it not all that bad - you not "updating" the session() value by doing this, so it certainly does not have to be written back each time (for a post) and also it means that a lock on session() during post backs etc. should not occur.
I would however consider one of the above two approaches, since then session() re-sets or anything else would not matter to get the user ID, or email.
As noted, this much depends on what security and authentication provider you are using here.
What we have currently implemented works well but I'm just concerned that there maybe a better way or we are doing it completely wrong.
Once logged into our website, on each and every request it will make a request to the API to get the users details.
E.g. Username, ImageUrl, Roles / Permissions, Email Address etc
It then stores this data in the BaseController for the viewpage or anyone else to see during that request.
Upside:
to doing it this way is that you know each request that the users permissions/roles and their details are all up to date!
Downside:
Your most likely to get exactly the same data every request, until that one day they change their details. Thus your possibly making unnecessary calls??
However the first way we tried all this was when the user logged in all their data gets stored in the cookie, the problem with this is that our users hardly ever logout so all the data that is stored in the cookie gets stale often. -> Stale Roles/Permissions is an annoying issue!!!
How does everyone get around the stale data from login.
I would go back to your initial approach of storing the claims inside the cookie.
If you do indeed have very long log in times then I would guard against stagnant claims by periodically refreshing the cookie.
If you are using forms authentication then you could intercept the FormsAuthentication_OnAuthenticate event in Global.asax, decrypt and manage the cookie (here), validate the user and cookie first then run a quick conditional check against a custom field in the userdata property, called refreshedDate.
If the last refresh date or creation date is greater than some configurable window then call to the database and refresh the claim data from the database. Finally update the refreshDate and claim data and update the cookie.
Update
Following on from your comment...
Just to say that it is not uncommon to hit the database for each request, that is to say I have known it happen in a number of production systems. Many people are probably using ASP.NET session state using MS-SQL database's. Typically I have seen it when there is a real security need to invalidate someone's session, deny access and log them out immediately.
If your database is on the network locally to your web servers and/or latency is acceptably low then it can be a perfectly workable solution. Just make sure your database queries are minimal and performance tuned to perfection, consider side steeping any ORM (if applicable) and use raw SQL connections to make things as fast a possible.
If database latency is high, the other middle ground solution is caching, using Redis or Memcached to house the results of your queries and invalidating the cache when permissions are altered etc... but obviously adding the required infrastructure and operational support for caching solutions is a serious consideration.
You can apply an expiration to the cookie; that way it dies and requires them to login. Or, keep their user ID in the cookie, but store their profile info in session. When session dies, the next time the profile is checked if it is null, make a query to the API again. This way, it's getting updated more frequently.
In addition to other suggestions, another option may be to use a notification mechanism from the underlying role/permission store whenever a user's data changes. This notification could then be used to invalidate the cached data on the web server. This would ensure that the cached data is returned in the majority cases but the store would then be hit only when the data had changed.
If the underlying datastore is SQL Serevr then consider something like SqlDependency.
This is obviously a more complex architecture but it would meet your requirement and only you could say whether it's worth the effort / complexity / tradeoff!
I've recently been developing a website using asp.net webforms that uses in proc sessions and I noticed that session ids are shared amongst browser tabs. So I was wondering what you would do for the following situations:
Problem:
Multiple logins with different users in the one browser problem
User opens browser tab 1, logins
with "user1" - store in
session
User opens browser tab 2, logins with "user2" - store in session
At this stage session information is now pointing to "user2" because of how session id is shared amongst browser
tabs
User tries an action on tab 1 and suddenly they have "user2"
information
How do you alert the user in tab 1 that the user has changed or how do force tab1 user to logout?
My initial thought was to keep a list of active users with session id via database or application object, but the problem I face is that in tab 1 what am I going to compare the list against, when I do a request the HttpContext.Current.User would be updated with "user2" how do I know browser tab 1 was initially for "user1"
Appreciate anyone letting me know of any alternatives or best practices for the above problem
Regards DotnetShadow
Why don't you warn when user2 logs in instead? With a message like "You are already logged in as user1, are you sure you want to login again as another user?"
All tabs in a browser belong to the same instance, so all tabs share cookies and sessions, there isnt much you can do about it. If you want to implement this badly the only solution that comes to mind is carrying a unique session id with each URL. Based on that unique id you can link a specific user. You will need customize the session logic and would have to make sure all links in your website carry this unique id. It could be done with alot of effort but the real question is , is it worth doing?
Some have suggested adding uniquifiers into the URL, and tracking based on those.
If you're going to do this, you may as well just let ASP.Net do this for you by turning on cookieless sessions - it then uses the URL to contain the session ID.
That's just how it is. You can't do much about it. Users are now accustomed to this behavior as it is consistent among famous internet sites like gmail, etc... so it shouldn't be much of a problem to them.
What I do to avoid this problem is redirect to append a short, random in-url login-identifier.
Then, rather than use session directly, I store a strongly typed object in the session vars under the random in-url code, and use that object for session storage. If you want to keep it simple, you could use a Dictionary. In addition to the normal session timeout, you should keep track of the last usage within each login-id and manually time-out a session if it's too old to avoid new users from keeping old logins alive.
Essentially then, each ASP.NET session corresponds to any number of login sessions.
This has the following advantages:
You can log in as multiple users simultaneously. That's handy to be able to do for many sites.
In public terminals, it helps avoid accidental session hijacking. When a user leaves a public terminal, closes the webapp tab but not the browser (which is quite common) and another person then approaches that terminal and opens a new window or tab to your site, this new user sees no trace of the previously logged in user. Of course, users should log out, and anyone can inspect the history, but there's no reason to invite abuse.
CSRF attacks against your site are a little bit harder since a url without the random login-id is meaningless.
The implemenation is quite simple if you use a hashtable - after all, any sessionstate-consumer already is written to store and retrieve data from a hashtable, you just need to change the hashtable it's using and should ideally include a custom timeout.
The obvious downside is that you need to include the random code in the url; and that you need a bit of extra implementation. You might hide the extra code using an iframe and/or javascript+XHR based site, but doing so is a much more invasive change to a site. Finally, note that cookieless sessions are not the same; though they're simpler to turn on, they involve a much longer less human-friendly url token, and by lacking the normal cookie session token, also are less secure vs. session hijacking (since suddenly any other program or even machine that discovers the session ID can pretend to be that user).
How about storing the data in viewstate? That would be unique to every window.
I'm using Forms authentication in ASP.NET MVC website and I store user account login name in AuthCookie like this:
FormsAuthentication.SetAuthCookie(account.Login, false);
I want to ask if there is a possibility that user on client side will somehow manage to change his login name in AuthCookie and thus he will be for example impersonated as someone with higher privileges and authorized to do more actions than he is normally supposed to have. Also is it better to save in this cookie user account login name or user account ID number?
The cookie will be encrypted and decrypted on the server side, so unless the user can crack the encryption key, he or she won't be able to do this.
As long as the information you store uniquely identifies your user, the choice as to what that information is is entirely down to the requirements of the particular application.
No it is not possible (well, in theory maybe but it's not feasible in practice). The value of the authentication cookie is encrypted so the user can not tamper with it. It is a good idea to store the (unique) login name in the authentication cookie, because when the IIdentity object (HttpContext.Current.User) is restored, the value that you passed to SetAuthCookie is used for the Name property of the IIdentity. The Name property will be shown if you use the LoginStatusControl, for example, so it's a good idea that the value of the Name property makes sense to the user.
Cookies are encrypted so chances for that a quite slim. But still.
More than one property approach
If you'd like to make your security even tighter you could save username as well as user ID or some other data that can't be guessed from the username. The combination of these makes it safer because if you can guess one it harder to guess others and use the correct combination of them. Ie. If you guess other user's email/username it's a bit harder to guess the same user's ID, because they're not related. So the more unrelated properties you combine the more steps it takes to get the right combination.
Logon security token approach
You could use an alternative approach described in this scenario:
User logs in.
Generate a random security logon token that can be of random length with some minimum length defined and save it against user in the data store. This is probably not a problem while it's quite common that other data is stored at logons as well like LastLogonDate info.
Use this token and save it in the cookie instead of usernames or other info.
If user logs-out, clear logon security token from the data store
User logs in again... go back to 1 and create a new token again and use it in this session.
This way it will make it safer on the long run, because this information will change on each login and if user does manually logout you can always clear that token from the store, so it won't at all be possible to inject someone else's identity. This does make it a but more complicated to use permanent cookies though but it can still be done.
This approach is not bullet proof but it provides additional security level that prevents the same attack over and over again when one account has been compromised. And also when one account is compromised it doesn't mean that others can be as well. If your security tokens are long enough it would be much harder to start a brute force attack on your site and while this kind of attack would be executed security tokens will change so it is definitely safer.
In our application, we have a need for a user to "impersonate" a different user. Think of it as a hierarchy -- Bob is above Frank in a hierarchy. Bob is logged in, and he needs to do things in the system for a short time as Frank. So, we have given Bob a list of users that report to him, and an impersonate link. He clicks on this link, and, behind the scenes, I log Bob out, and log in as Frank. I also set a session variable that tells me that really Bob is they guy who is the user. Also, Bob (acting as Frank now) has a nice little link at the top of every page that says "Stop Impersonation."
In addition, when Bob is impersonating Frank, Bob is restricted from doing some things, like changing Frank's password.
This was working great, until we encountered a situation where, if the session (I think -- getting confused here) gets destroyed (such as when I copy up new code and dlls to the live site), then when Bob clicks on "Stop Impersonation" he gets redirected to the default page, and is still logged in as Frank, but without the Impersonation session variable. So, now Bob really is logged in as Frank, and can change Frank's password (among other things).
How is it that a session variable (Impersonation) gets destroyed, but I guess the session is still hanging around, because it doesn't make the user log in again?
This is a somewhat serious bug for how our system works (bug in our code, I'm sure, not in .Net). Does anyone have any suggestions for a solution for this?
We are using ASP.Net c#, aspnet membership services, .net 3.5, forms auth...not sure what else you need to know.
EDIT: Updated information. Looks like when "something" happens, for instance, when I recompile some dlls and copy them to the webserver, the session gets dumped. Or, rather, the variables in the session get dumped. The session id stays the same. I do get to check for Session.IsNewSession and it returns true, even though the id is the same as it was before.
Just like Utaal mentioned, Membership Services is separate from Session, so it's forms auth token is still hanging around in the browser, but my session variable telling me that that isn't really the user who is controlling the browser isn't there anymore.
EDIT: Sky, here is what I'm doing to authenticate a user. I can't figure out where I would insert a ticket into this flow:
if (Membership.ValidateUser(txtUserName.Text, txtPassword.Text))
FormsAuthentication.SetAuthCookie(txtUserName.Text, false);
So, where can I slip in a ticket object and set my own information?
Matt,
Use the UserData slot on the forms ticket to store the impersonation information. That is what it is for.
Then your info will not get lost with the session.
If you would like a simple example of creating your own ticket, amongst other things, check this. You may want to focus on the login page and the tickethelper class.
I think your problem is due to the fact that Forms Authentication and Session are two different things and are not interconnected: both of them (usually) use cookies but Forms Authentication stores the encrypted logged-in user directly in the cookie while Session stores information in-process (even if you can change this behaviour) and uses a cookie with a session identifier to retrieve it.
So, when your session information gets lost (or session expires) it isn't really still hanging around (except for the invalid session cookie on the user's pc). On the other hand the Forms Authentication cookie is still valid (ASP.NET decrypts it and authenticates the user for the request).
A possible solution is to detect the creation of a new session (using HttpSessionState.IsNewSession MSDN) and sign out the user (using FormsAuthentication). You can then redirect user to login page.