I am looking through the Ruby on Rails tutorial book by Michael Hartl. In chapter 9 he talks about session cookies being removed after the user closes down their browser. To make sure a user is logged in during subsequent visits a separate and persistent cookie can be created.
He described session cookies (as implemented by rails) as being secure. So the question is why have a session cookie that expires? I understand that it will no longer have to be called a session cookie and you would have to make sure the cookie was under the 4kb limit. A session cookie would then act as a secure "remember me" for the remainder of its life.
Why don't sites make their session cookies permanent?
In the Ruby on Rails tutorial, he also told us the four main ways to steal cookies. Keep that in mind.
We have to distinguish two types of cookie. One is persistent, the other is per session.
Microsoft defines them as:
Persistent cookies are stored for a length of time that is set by the Web server when it passes the cookie to Internet Explorer. These cookies are used to store state information between visits to a site.
Per-session cookies are used to store state information only within a session. These cookies are cached only while a user is visiting the Web server issuing the per-session cookie and are deleted from the cache when the user closes the session.
We use the persistent cookies to tell who the user is. Nevertheless, the expiration date is just up to you. You can set it whatever you like. But when it expires, the user have to log in again.
For the developers, maybe someone think it's more secure to let the user to remember and type it again and again.
Honestly, it would be much safer to ask the password when the user is doing something critical even after they logged in.
I believe the session is in fact persistent and many sites I have worked with have made them permanent and used them to log a user in and keep track of them.
Related
How can we prevent session hijacking in an asp.net mvc application? The following steps were performed by the testers to hijack the session - OWASP A2.
Login as a low-privilege user.
Login as a admin user. (in a separate browser - from the same machine)
Copied the ASP.Net Session ID of the admin user
Replaced the ASP.Net Session ID of the low-prev user with the that of the admin user.
By doing the above steps, the low-prev user was able to access the admin areas of the app.
The application is hosted with SSL (https).
Cookies have been set to Secure and HttpOnly.
Cookies are set to expire on Session_End and Signout.
Still, I am able to reproduce the scenario explained above using Fiddler. Could someone please help on ways to arrest the above issue.
Thanks.
I would argue that if someone were able to still the cookie, then she should be able to log in. The mitigation should be using short-lived cookies for sensitive resources, and require the user to re-enter her credentials before doing any sensitive data. For example, setting a password, granting permissions etc. Also, you should make it hard to still a cookie - which seems like you already did. Worth also adding Same-Site), and keeping your site secure.
In my application I have used several session variables, but not given any session timeout in web.config. I have used authentication mode as none in web.config.
But after some inactivity time, its logging out and redirecting to login page. It should remain and all operations should carry as it is even though I kept it inactive for hours (like GMail, until we click logout it will be there). Please assist me in resolving this inactivity session out issue. It should not loose any sessions and operations should carry until I click explicitly "LogOut"
Best approach to handle this is,
Save user session on the database and store session token in a COOKIE which will never expire (You have set cookie expiry as never expire)
That saved cookie and session data on database will be removed when user is logout (You have modify logout code to remove those).
As well as, if user clears all saved cookies on the web browser then, that saved session no longer valid and user will have to login again to your system again. That is a obvious thing
FYI: This is the way exactly to enable Remember me feature.
I need some clarity around how cookie-based sessions work. I'm building an app where I authenticate a user and upon successful authentication, I stick a GUID identifying his user into the session, which in turn gets persisted as a cookie. Now when a user logs in, whats to prevent someone from sniffing traffic, stealing the contents of the user's cookie and creating a cookie on their own end and login to my site as that person? Another scenario could be if I had physical access to a machine where the person was logged in, I could also steal the contents of the cookie and impersonate as the user.
Whats to prevent someone from sniffing traffic, stealing the contents of the user's cookie and creating a cookie on their own end and login to my site as that person?
SSL - the only way to stop that is to run your web site on HTTPS.
I had physical access to a machine where the person was logged in
Once you have physical access to a machine all your security methods are moot. You can do nothing about this.
I think you have two questions here. In regard to the second you should not be storing a session key in a cookie and have it stick around longer than the session, set the timeout on the cookie to expire quickly and invalidate the session on the server as soon as reasonable and the cookie becomes useless. If you are flowing important information over the wire use https.
How do I detect in devise when the user's access tokens are stale and thus logging the user out?
Why do you need this? There is timeoutable option exist that allows to track session timeout. I might be wrong, but tokens are cookies keys that have time to live and they are tracked by browser. From Devise (hooks):
Each time a record is set we check whether its session has already timed out
or not, based on last request time. If so, the record is logged out and
redirected to the sign in page. Also, each time the request comes and the
record is set, we set the last request time inside it's scoped session to
verify timeout in the following request.
---- UPDATE (to not put in commets as its large)---
In the most cases, when you use is logged in, there is no requirements to get authentication from external servises. So in the cases when user is logged in (i.e. session cookie present and session is valid), and in the same time she logs out from external servise that means that she can use your site until your session is expires. Again, the external service is used once user requires authentication. So when session is expired on your site and user trying to log in using external service she will be redirected to external site where she will log in (or not if already). Then external service redirects back to your site provided callback (in the most cases path is /auth/:provider/callback) where your controller (or default provided by devise) will create if required an user and a session for him.
I am reading a great Rails tutorial and came across a passage that I had a question about:
Box 9.2.Sessions and cookies Because
HTTP is a stateless protocol, web
applications requiring user signin
must implement a way to track each
user’s progress from page to page. One
technique for maintaining the user
signin status is to use a traditional
Rails session (via the special session
function) to store a remember token
equal to the user’s id:
session[:remember_token] = user.id
This session object makes the user id
available from page to page by storing
it in a cookie that expires upon
browser close. On each page, the
application can simply call
User.find_by_id(session[:remember_token])
to retrieve the user. Because of the
way Rails handles sessions, this
process is secure; if a malicious user
tries to spoof the user id, Rails will
detect a mismatch based on a special
session id generated for each session.
For our application’s design choice,
which involves persistent
sessions—that is, signin status that
lasts even after browser close—storing
the user id is a security hole. As
soon as we break the tie between the
special session id and the stored user
id, a malicious user could sign in as
that user with a remember_token equal
to the user’s id. To fix this flaw, we
generate a unique, secure remember
token for each user based on the
user’s salt and id. Moreover, a
permanent remember token would also
represent a security hole—by
inspecting the browser cookies, a
malicious user could find the token
and then use it to sign in from any
other computer, any time. We solve
this by adding a timestamp to the
token, and reset the token every time
the user signs into the application.
This results in a persistent session
essentially impervious to attack.
I don't understand what this is saying. I take from it that a unique session ID is created and stored on the client in a cookie. Then when that cookie is sent to the server on a request, the server knows that is the user in question so that the login can be persisted. However, if a malicious user stole the cookie, I don't understand why they can't log in from another computer. The author says this is solved by adding a timestamp, but I don't see how that helps. Further, the author says that the token is reset every time the user signs in, but the whole point is a persistent sign in, so I don't understand. Please help!
You are correct—a "Remember Me" cookie can be used to steal a login. The issue that they're trying to resolve are if someone steals your cookie, containing your unique identifier, and hangs on to it—they'd then be able to log into your account at any point in the future.
The usual solution is to invalidate all previous cookies every time that you log into your account using either the username/password or the "Remember Me" cookie, so that a given cookie will allow you to login a single time. The timestamp is how they're ensuring the uniqueness of each cookie.
If you're worried about cookies being stolen, a typical solution is to also store the IP address that the request came from, and if the IP address that the cookie is coming from doesn't match the IP address that the cookie was created from, deny the login and force the user to sign in. This can be inconvenient to users who are behind dynamic proxies, or who carry their laptop to and from work/home/coffee-shop, since their IP address will change all the time.
"Remember Me" is a security hole by design. The goal is to limit how much of a hole it is, and if you're designing a system that requires absolute security, it's not a good choice. If convenience is more relevant than security, using timestamps and cookie invalidation limits the potential security issues.
If you're interested in more information on this topic, the Security Guide section of Rails Guides has an entire section on sessions.