7
Thinking about security guard, what is the best option to keep the user logged in an ASP.NET MVC application, the cookie or the Session?
2 answers
16
Safe is doing right. It is mastering the subject, knowing all the possible vulnerabilities of each mechanism, knowing when and for what it can be used. Depends on each case.
Are you using SSL? This makes a difference in security.
Which is safer
Anyway I prefer sessions because it is not stored in the browser. The cookie can be tampered with or captured. But depending on how it is used there is no problem. Just never put sensitive information in a cookie.
There are controversies whether to use a cookie to keep a user logged in or not logged in, many important websites do. In theory it is dangerous, but it is a calculated danger and the safety of the user is that it can be compromised, not the security of the web application. Obviously you can’t make something safe that you don’t have control of, so if it’s really necessary, don’t let the user "log in" by a browser control mechanism.
A session can use a cookie to keep it active (depends on the implementation, the current uses). She’s in charge of doing what’s necessary to maintain his safety, she already has a proven standard of security. It is a more abstract way of taking care of safety. Of course it is still necessary to take some care.
The session keeps server-side data, which is a huge advantage over cookies pure.
I see some people say use cookies and not Session. But it depends on what it’s used for. People who have experience with it live by using sessions. Of course they do it knowing how to use, as I said right at the beginning.
It is possible to use ASP.NET Identity which is another abstraction layer to obtain a mechanism of session control (yes, it has a session control built into it), among other things.
Deep down everything wears cookie, just choose the abstraction layer you want.
I would never say to use one or the other without knowing the specific case. I will not apply a general "good practice". Each mechanism has its usefulness, advantage and disadvantage. And mainly I wouldn’t say not to use anything unless there is a clear fact not to use, if, for example, the supplier made it obsolete and gave a good reason not to use that anymore. This is not the case with the mechanisms mentioned in the question.
The specific issue on the functioning and difference between the two mechanisms has already been widely answered here at Sopt. The question does not ask and I will not go into details, after all it is more specific. For example: What’s the difference between Sessions and Cookies.
-
1
in the case of login without ssl , if a man in the Middle steals the cookie he usually takes along the session
-
@Johndiego that’s right.
-
You don’t even need a man in the Middle if it’s a broadcast network like WIFI. Remembering that nothing is 100% safe, there are techniques capable of stealing even with SSL.
-
1
@Daniloloko Yes, it has several forms. Although I think that what you quoted is still a MITM.
-
@Bigown, I take the answer wrong because she’s, shall we say, poorly worded. The answer itself is correct, but I had to read and reread it four times for the words to make sense. I think you could improve a little especially the last 2 paragraphs. And add on how to Session uses the cookie sent by the browser to recognize the user and store information on the server, temporarily.
-
@tayllan I do not know if you have negative. Negative serves for wrong answer. But maybe they decided to negativize something, the other also negatively (it is true that she does not speak what was asked, supposes things, but still do not think it deserves negative). I didn’t go into too much detail because the question isn’t specific, it doesn’t ask about the details of how each thing works, as you suggest I do. But then I make it better.
-
@bigown, exact for wrong answer. So I was negative (yes, I was :)), because I read it and I couldn’t properly understand his answer. I’m waiting for your edition to remove the downvote.
-
2
@tayllan is that you said she is correct, so the negative was incoherent.
-4
Use ASPNET Identity to manage your users' authentication. It already predicts several security issues and is super easy to work with.
The ideal is to use a cookie to record non-safety information. For example, user preferences, last pages or viewed products, when you were on your site for the last time - for an access counter control, maybe.
And if it’s web, DON’T USE SESSION.
- Sessions are allocated in the IIS Pool: when Apppool memory is recycled, your data stored in Session is released;
- Sessions are of exclusive access: Whenever an access to the Session is made, every execution pipe is locked until the access is finalized. So you can only have one access to Session at a time. Imagine this with multiple users connected simultaneously.
- Session are not scalable: As it is allocated in Apppool, if hosted on scalable servers, this information will not be shared among other hosts. So if your app uses Session, it’s not possible to scale horizontally.
That’s why we use Cache instead of Session. And that’s also why there are several Cache solutions on the market today.
Just don’t forget that Cache is shared throughout the application. So if you’re going to cache a user’s data, simply Cache["DadosDoUsuario" + UsuarioId] and be happy.
You can use the System.Web.Caching.Cache per hour, and if you really need to invest in Cache data, go to a Ravendb or Redis.
But Session? Say no to Sessions.
-
1
you’ve heard of
Session-State? you are not forced to use theSessionInProc... can use theSqlServer, theStateServeror evenCustom -
@Tobymosque, it’s exactly from
Session-Statewhich I mean. And we’re talking in the context of application, within ASPNET. Sqlserver’s session is another type of session, outside of the application. -
Those who have spoken against.
-
indepedent of
Session-State, toSessionremains the same, what changes is the way the data is stored... an analogy would be Entity Framework and EF Provider, modify the Provider does not make the EF a different ORM, but rather how it will store the data. -
Yes, exactly. And what I posted is that I strongly recommend not to use the
System.Web.Caching.Cache. Other data persistence components are not in question in my post. -
Speaking of Cache, I even agree with you not to use the
System.Web.Caching.Cache, also agree that Nosql may be an alternative to Cache... but speaking of Cache, what do you think of theAppFabric In-Memory Cache Platform, afinald is a free distributed Cache solution from Microsoft itself?
Browser other questions tagged asp.net-mvc .net security-guard session cookies
You are not signed in. Login or sign up in order to post.
Session uses cookies. They work together, Session on the server and cookie on the client.
– Silvio Andorinha
I didn’t quite understand the negatives, but so much to improve the question to see if it reverses.
– Maniero
I did not deny, but marked as duplicate, because although both questions are different, yes to the answers there http://answall.com/a/115198/3635 already explain why one is supposedly safer than the other, however if you disagree you can comment here on your point of view :)
– Guilherme Nascimento
Jedaias, please, take a look at my answer.
Sessionsof ASPNET are not a good, and having marked as the right answer can induce others to follow a bad path.– Thiago Lunardi