How do i remember sessions, even after browser is closed.
is there any alternative than extending expire time of cookies.
i am using code igniter
I implement my version based on this article. The article explain a concept, security, and how to implement persistent login cookie.
The summary of what I done is:
Create a table to hold persistent cookie series and token (series is needed to detect if the cookies got stolen).
I write the model to create required cookies (separated from normal CI session).
The model also do database
read/write of the used persistent
cookies.
I integrate this model to existing user model that handle
normal authentication.
When user go to page that need relaxed authentication, without
normal CI session, but have
persistent cookie session in his
browser, my code will recognize it
since the same series and token also
stored in the database. The user
will got a normal CI session, but
with a flag that this session is
generated from persistent cookies,
not from login form.
When the user go to 'sensitive' page that demand a CI session
without persistent flag, then user
will be logged of, and sent to login
form (if you use yahoo mail, then it
similar with that). This usually the
page where user can do
add/edit/delete, and see sensitive
information.
I hope this help.
The cookies is that only solution i suspect. As you said, you need to extend the time. However if you wanted to use PHP sessions instead, you to make sessions life longer using php.ini file but i don't think using sessions for this purpose will be a good idea because data of sessions is stored on server rather than individual user.
Thanks
Related
I'm trying to develop a website for reviewing TV series, and I want to limit the rating for a show to one rating per user, and I kind of have no idea where to start, since I'm very new to web development. I'm using Vue.js on the front-end; Node.js with Express on the back-end.
From what I understand, cookies should not be suitable for this purpose since they can be deleted by the user, am I right?
I've also read about sessions and how they are stored on the server rather than the browser (but I also don't know what sessions are or how to implement them).
There's also the user registration system possibility. So, which one of these methods should I use for this purpose?
If you could also tell me about where to start (direct me to tutorials, code snippets, ..) I would be really grateful. Thanks.
Like said by Mr. Anonymous, you need User Accounts. However you could achieve this using in your case, for example, expressjs/session to create sessions and passport.js for the user authentication part.
Here there is a simple tutorial using these two libraries and mongo-db for saving user data.
If you want implement your own session library (only for learning purpose), you can follow these advices.
You need to use all 3 and if your new to web development this will take you some time to get right. You will need user registration, a login system, and when users log in you will create sessions ( which internally use cookies) and if you want them to login with "remember me" you need to explicitly use cookies.
Sessions
This is how express/your-web-app will remember that a user is logged in. Under the hood its using cookies on the users machine that map to ids stored in memory on your server. Without sessions and cookies your users will have to log in on every page....You don't have to worry about how sessions use cookies yourself. There is express middleware libraries that handle this for you so you just interact with sessions like any other object, but its good to know that sessions internally use cookies. You can find lots of articles expanding on this.
Cookies
You will explicitly have to create cookies if you want to give your users the "Remember Me" login option. If you don't care about that then you can force them to log in and then create a session so they wont have to log in again for 20 mins or however long you want.
User Accounts
User accounts are records in a database that uniquely identify each user. The sessions and cookies all point back to this. That is where your store your users information such as their username, email, and whether or not they have already voted on a TV series. When a user logs in you lookup their identity in your database and if you find one you then create a session so they don't have log in again as they navigate your site for a set amount of time.
Recommendation
Start small. Forget about Vue.js for now and use plain HTML until you understand these basic components sessions, cookies, and how to build a login and registration page. If, and I respectfully mean if, you get that working then you can work on making it look pretty and fancy in the front using Vue.js.
So I just read this article by Jeff Atwood and I wanted to make sure I understand it correctly as to how it applies to my use case. I am trying to validate a session for silent login. For security purposes this should be done with a POST right? Does it matter? I am just passing the sessionID and username from the cookie.
When it comes to CSRF (Cross-site request forgery), you can cause a user to take any action on any site which they are logged in to provided that the action requires only a GET. Forcing this to be done over a POST request defeats the approach of embedding an image, script tag, whatever in another page.
Even POST isn't completely secure in this scenario. There are other ways to mount a CSRF attack on a site using POST. Clickjacking/UI-Redressing enables another site to trick a user into submitting a form to a different website.
Basically the best way to validate is to add an automatically generated, hidden form element. You can store this inside your session data (Example: $_SESSION for PHP) so that you only need to generate a token at the start of a session. Of course, an attack could try do something like clickjacking (mentioned above) in combination with a iframe pointing directly to your site and possibly some JS to hide things a little.
For anything important you should re-prompt the user for their password, thereby greatly diminishing the value of any successful CSRF attacks.
I wrote a simple webserver with nodejs and express. I implemented an user authentication with email username and password. Furthermore I have a remember-function which stores the user id and pwd hash into a cookie. Now I would like an extra session that ends when the user will close his browser or click to the logout button.
Which way is the best practice for implementation? Is the session the same like the remember-function with an expire time and in each request I must check the credentials against the database? (I'm not that sure about this)
Technologies that I'm using: nodejs, express, mongodb
This is not a nodejs question only, I would prefer a general explanation for the problem.
Let me get this out of the way first; Storing the password hash into a cookie would allow anyone to login when they have the password hash and that would be disastrous if the password hashes ever got exposed for some reason. Encrypting cookies is just fine, but don't allow the actual hash you store in the database to be used for authentication. Ever.
About re-authentication, Node is a technology that operates on a single thread and is scaled by running more instances over multiple processors and/or machines. Keeping sessions is a good idea to avoid trips to the database, but you have to think about the architecture as well. What happens if you, say, use sessions stored in files (ala PHP) and you need to scale to multiple machines? Nothing good, at least. So you need a central point to keep track of the sessions.
This can be either your database (MongoDB) or something such as Redis, or another centralized mechanism allowing you to check sessions. Either way, you will have to spend time doing the request and retrieving the session values for the client. If you do not have additional values you need to store it makes no sense to create a dedicated session architecture (that needs expiration, and so forth) and just doing the authentication again is the easiest and most logical solution.
Personally I almost never need sessions and just do authentication again.
Most web sites you can log on to also provide the feature so it remembers you between sessions.
What's the accepted and secure techniques for implementing that ? (What do you put in the cookies and how do you handle it on the server/db?)
This recent 2009 chapter in Spring Security 3.0 discusses Remember-Me type authentication. The general concepts are not specific to Spring Security so you should be able to benefit from it even if you are not using it. The chapter also cites a Barry Jaspan's 2006 blog posting which is an improvement over the techniques described in Charles Miller's 2004 blog posting.
The blog entry basically comes down to:
When the user successfully logs in with Remember Me checked, a login cookie is issued in addition to the standard session management cookie.
The login cookie contains the user's username, a series identifier, and a token. The series and token are unguessable random numbers from a suitably large space. All three are stored together in a database table.
When a non-logged-in user visits the site and presents a login cookie, the username, series, and token are looked up in the database.
If the triplet is present, the user is considered authenticated. The used token is removed from the database. A new token is generated, stored in database with the username and the same series identifier, and a new login cookie containing all three is issued to the user.
If the username and series are present but the token does not match, a theft is assumed. The user receives a strongly worded warning and all of the user's remembered sessions are deleted.
If the username and series are not present, the login cookie is ignored.
Signed cookies that can not be tampered with can be a good idea when you don't require a whole server-side state ... lean mean and efficient.
You still run the risk of cookie theft but you can always sign the cookie using IP address, User-agent and other things to help minimize the threat.
It's just a cookie with a long life value assigned. However it will only work so long as the cookie exists. For example, I have my Firefox set to clear my cookies when I close the browser. So this wouldn't work for me.
Cookies, but the user can decide to delete it.
In the same spirit there is some kind of solution, using Flash. Flash can store informations on the client-side, not a cookie, it's not erased (usually) by the browser. With it, you can remeber which user is asking for pages, but you're stuck using a plugin-using solution, and need to know Flash..
I don't see any other solutions.
Do not try to implement session cookies yourself.
Most web frameworks give you an abstraction over this, leaving you care-free about the many security issues you might be exposing yourself to.
A simple API in pseudo-code in a web framework might look something like this, on login:
authFrwk.loginUser(request.POST.get(username), request.POST.get(password));
This will return a cookie to the client (handled exclusively by the framework).
A securely authorized operation will look something like this:
if (authFrwk.isLoggedOn()) // implicitly checks user session cookie
doSomethingImportant();
else
return notLoggedInMsg();
Basically, a session cookie is given a unique ID on the server-side, which a malacious user cannot generate/guess by himself, and which identifies the client as a logged-on user.
I would like to improve security on a current application regarding session management and I want the users to be logged in until they explicitly logout.
How does one implement that securely?
Keep session information in database, like sessionid, ip, useragent?
Please provide the requirements, possibly a database layout, do's and don'ts, tips and tricks.
Note:
I know frameworks like asp.NET, rails, codeigniter, etc... already take care of that, but this is not an option. Actually it for a classic asp application. But I think this question does not relate to a specific language.
Read Improved Persistent Login Cookie Best Practice (both the article and comments).
You should know that such a system cannot be secure unless you use https.
It's quite simple:
User logs in.
The server sends the user a cookie with an expire date far in the future.
If you want, you can record the IP of the user.
User requests another page.
The server checks the cookie (possibly the IP stored with the cookie), sees that the user is logged in, and servers the page.
Some security considerations:
As stated above, there is no secure way unless you use https.
If you're using shared hosting, try to find out where your cookies are stored. Often they reside in the /tmp directory, where every user as access to and through that someone could possibly steal your cookies.
Track the IP, if you know that the computer isn't ever going to change it.
Don't store any information in the cookie. Just store a random number there and store the information belonging to it on the server in a database. (Not sensitive information like preferred colour can be stored in the cookie, of course.)
Create a cookie with a ridiculous expiry like 2030 or something. If you need session state, keep a session ID in the cookie (encrypted if security is priority) and map that to a table in a database. IP/UserAgent etc. tend to be meta-data, the cookie is the key to the session.