I'm working on a legacy application using ASP.NET Web Forms, and I need to implement the "Remember Me" functionality when the user logs in (as in, does not require the user to log in unless their username/password has changed). What is the best approach to doing this? I've found posts like this one or this one but these are incredibly old and was wondering if there is an updated practice to doing this. TIA!
I believe the standard generally speaking is to create some kind of unique/random token and store it in the customer's cookies. On the back end, you save that token associated to the username, so when the customer is browsing you can check the token in their cookies and compare it to what you have on file in the database. I'm sure there are a variety of opinions on how exactly to implement all that, as you can see in that first link you mentioned, but using some kind of token in a cookie is what I've seen in many places.
Related
I am trying to implement "Remember Me functionality" in PingFederate. For doing this I am trying t implement cookie based authentication. Before working on this I want to know any of you already worked on this and what are your thoughts ?
Please let me know.
Thanks!
First off, just to get it out of the way, I work for Ping Identity. Always good to have that up front.
Second, there may be some clarification in order, but if you're wanting to configure "remember me" functionality... Doesn't that defeat the concept of authentication? Don't you want to protect the resources that PingFed enables access to? Allowing "remember me" may be fine for something like Facebook, or WordPress, but I sure wouldn't put it in front of anything financial or health related (in fact, there are regulations against such a thing).
Finally, to actually answer your question... You'll need to create your own authentication adapter, likely built around our OpenToken SDK. The way I would handle it is to authenticate a user against whatever user repository, and create a "long-lived" cookie, one that is good for X number of days, and refreshes every time it gets used. That cookie cookie can generate an OpenToken, providing access into PF and its protected resources. You should make it so that token is a hash of something... Like a salted hash of the machine's MAC address or something similar that ties the cookie to that machine.
Again, though, I want to caution you against "remember me". It just seems like you're reducing security.
I'm using VS2010,C#,SQL Server to develop my ASP.NET web app, although this is not my first ASP.NET experience, but this time my project is more attack-prone and I should consider better security polices. I have a login screen as my first page, users enter their user name and password and a page specific to them is showed, in my last project, I used query strings (a userid) along with sessions for security purposes, but this time I've used just query strings, it means that at the moment one can enter myaddress.com?userid=1 and visit a page in my site!!!
I know this is not good, but what are my approaches, of courses I'm not working with banking or financial systems but I'm going to have an standard security policy, I should use sessions? cookies? can you suggest me an easy-to-develop and meanwhile secure way of implementing protection policies? any sample code or tips?
thanks
ASP.NET actually comes with all of the facilities you need to provide a secure site out of the box so you don't have to worry about all of these things yourself.
Use the built-in ASP.NET Membership features and you'll be fine.
When a use is logged in (Through open-id) we are creating a session variable named "UID" and storing the unique user-id in it. Later we are checking the session to see if the user is logged in. I think this is not the right way, but I could not force the team to change this, as I cannot show how this implementation can be cracked. Can anybody show me why (If yes) this implementation is bad?
I can see no situation where you should worry about a server-side Session value being obtained through a client-side exploit. There has been some concern about fake OpenID providers tricking users into passing credentials because of the lack of stature to OpenID, but generally it's unwarranted.
The implementation seems acceptable, but given that you are using ASP.NET you should consider using IIdentity and this ASP.NET OpenID provider:
http://code.google.com/p/dotnetopenid/
It's well tested and has quite a bit of security code and API support built into it.
My first question would be, what is making you think this is not the right way?
Storing data in this way is very common, secure and it's localized specifically to a user. If you don't like using the session for other reasons such as handling sessions over multiple servers or having to serialize / deserialize the session to a data store (assuming non-memory session) then that is a different arguement but the security part shouldn't be the issue.
Also keep in mind the simplicty of using the session as well. It makes data access to user specific data that you need to access constantly, standard and consistent throughout your application.
EDIT based on comments:
I was wondering the same thing when I started using MVC as well and it seems to be totally fine. I couldn't find anything against the idea. I even asked this question because my custom authorize attribute had to access the session and I stored special role types in it that the out of the box authorization didn't quite fit.
As Nissan Fan stated, I can see no reason you should be fearful of a server-side session value being exploited.
Just out of curiosity, what are some of your reasons for thinking it's not the right way to go?
Im just wondering how to go about using FormAuthentication in asp.net
In our project we are basing it on webservices, which returns an XML document on successful login with all the credentials we require. Whats the best way to store and access the information returned?
Thanks
EDIT: thanks for the response. I cant use the default provider because the provider is already given to us.
Basically, what I want to know is whats the most effecient way to store a Guid and an Integer on successful login so that it can be easily accessed by my asp.net application.
When you create your FormsAuthenticationTicket, you can set the UserData property to anything you like, including the data from the web service. That data will all be encrypted when placed into the Forms Authentication cookie, and will be decrypted on each subsequent request. The information will be available in the Ticket property of the FormsIdentity object that you can reach via HttpContext.Current.User.Identity.
How to go about it? Its a complex subject which no one can answer fully here.
I can tell you that the easiest way to implement it is to use the standard SQL Server-backed forms authentication provider. This is a step-by-step on how to set it up.
It can get a little confusing when there are database issues, however. These are usually caused by common issues and some googling often straightens it out quickly.
Keep in mind, also, that forms authentication usually entails sending cleartext passwords across the network. So protecting your login URL with SSL is a must in a production environment.
Session["GUID"] = value;
Session["INT"] = value;
Shoving the XML Dom object or xml in the Session object is not advisable for performance reasons when you only need 2 tiny values.
I want to create a website that the login system shouldn't be handled by cookies, but on (a) table(s) in the local (on the server) SQL DB.
Is there a way to do it?
Even no partial way?
What and where should I save instead of the cookie???
ASP.NET uses Session cookies by default to track user requests. If you use Cookieless sessions, you will find the Session ID being appended in all requests from the browser. In many scenarios, this could also be unacceptable.
Even if you decide to hit the database and check for a "LoggedIn" flag upon each request, you still need some way to identify the incoming request as belonging to a particular user. This could be in the form of encrypted values in hidden fields, depending on your security scenario. That said, it's not a much better method than the use of cookies, because any data that comes from the client has the potential to have been tampered with.
Personally, I think Cookies are great to track user requests as long as you encrypt them properly.
You still need some way of telling the users apart. If you don't use cookies, then you will have to transfer that information in url or allow only one user from a single ip address (this is really stupid) ... or something else. Cookies are not that bad :-).
Cookieless ASP.NET
If you need help actually implementing the login system you'll need to include more details about your specific problem.
You can store your usernames and so in a database, but you will still need a way to recognize the user as he/she navigates from page to page. That is the cookies role in this, to persist this login token...
It is possible to implement some other ways of handling this token. One can use the URL or somme hidden fields (as ASP.NET's ViewState) to store this token.
So, yes; it can be done. But it takes some work, since you can't use what ASP.NET already provides you. (ASP.NET has builtin-features to handle this token as a cookie, and also store the credentials in the database.)
Use the SqlMembershipProvider.