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.
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.
Regardless of a language and framework, how does this work in a low level -- putting a variable into a session to authentication a user?
put_session(curr_connection, :current_user, user.id)
Does user user saved in a cookie? On a client? Then what prevents a user of a browser change it by storing id of any user they desire and get authenticated on behalf on that user? Or does user.id get saved on a server and on a client we have only a loooooong session id, in a cookie or in url?
The short answer is it depends. All languages / frameworks have their defaults, Ruby on Rails for example stores it in a cookie by default, PHP stores it on the server, etc. But in pretty much all of these languages, you can change your cookie store to whatever you want.
Some options (there may be more):
Cookies - In this case the cookie is encrypted before sent to the client. The key used for encryption is some sort of an application setting. This is somewhat secure, because even if session values are stored on the client, a user still cannot see or modify them, because he does not have the application key. The advantage of this is that it's very simple and requires zero setup, disadvantages include this being less secure than other solutions, and also the amount of data that can be stored in a cookie is limited.
Server memory - In this case, a cryptographically random session id is sent to the client, all session data is stored in the application server memory, identified by the session id. The advantage is that it's not written to disk and also not sent to the client. Disadvantages include the session data being lost when the application server is restarted.
Server Filesystem - The traditional approach (kind of), session data is stored in files so that it's persisted across application server restarts. In this case, access control to these files is key, but usually taken care of by the language or framework.
Server SQL Database - The traditional heavy-weight approach, all session data is stored in a relational database on either the application server or a separate database server. The advantage is that you have direct control to session contents of any suer, not just the logged on one (for example it's easy to do forced logout for an admin by removing session entries from the database). This same thing can also be a disadvantage in case of an application level attack. Also operation is more expensive.
Server NoSQL Database - About the same as a relational database, but a non-relational database like Redis can also be used. One drawback can be that access control in Redis is not very strong to say the least.
Session Service - In some enterprise applications you may want to implement some kind of a session service (RESTful or else). Obviously this just pushes the problem one layer back, session data must still be stored somewhere with one of the options above.
Your language or environment probably already supports some of these, and if you want one that is not supported out of the box, you can implement your own. However, session management is tricky business, it's quite easy to make it vulnerable. OWASP has a nice session management cheat sheet to consult.
Im trying to understand how a user can keep logged (i'm trying to implement this on Node without frameworks, for learning). Just a couple of questions based on what i think i understand:
(1) When the user tries to login, it sends the user and password in an HTTP request body
(2) When data arrives to the server, it checks everything needed like if the user exists and if the password is correct
And here comes, i think, my problem: How can the user keep logged? The third step would be something like:
(3) The server create all the session data needed, encrypts and send it to the client?
(4) The clients store the encrypted data in the localstorage
(5) The credentials are sended with every request to the server, and the server decrypts it and check it before processing every user's action.
That's what i understand. But i find this very extrange. I feel i missing a lot... storing data in client side doesn't seems (at least for me) secure. Should the session data be stored on server-side? And how the username and password should be sended securely? It must be encrypted client-side? Is this secure? I think im looking for some pattern or i don't know. I feel lost.
Yeah, and sorry my bad english and poor knowledge. Im not asking for code and i will also appreciate any hint (like what to search in google, or a interesting blog) :)
Thank you, y un abrazo :)
--- EDIT ---
Well, finally i founded some usefull links and solved great part of my doubts :)
[http://stackoverflow.com/questions/6922145/what-is-the-difference-between-server-side-cookie-and-client-side-cookie][1]
[http://blog.codinghorror.com/protecting-your-cookies-httponly/][2]
[http://www.cse.msu.edu/~alexliu/publications/Cookie/cookie.pdf][3]
[https://es.wikipedia.org/wiki/Cookie_(inform%C3%A1tica)][4]
[https://newspaint.wordpress.com/2015/09/06/how-to-get-cookies-from-node-js-http-response/][5]
1 and 2 are correct.
Sessions are usually implemented using cookies, not client-side local storage, because cookies are automatically sent to the server with each request. The cookie will often contain just a long randomly generated ID which refers to data stored on the server side, e.g. in a database. This data will identify the user and possibly store other session-level settings.
It is also possible to use a cookie with signed (and possibly encrypted) user information - for instance ASP.NET does this by default. This has the benefit that no storage is required for the session. The downside is that sessions cannot easily be destroyed from the server side. Therefore e.g. a feature that shows the user their currently active sessions (from other devices) and allows them to log them out couldn't be implemented.
Sending the username and password over the Internet should preferably be done securely, by using HTTPS. Do not implement your own encryption on the client-side. It will likely not work, plus the cookies themselves are viable to be stolen if the connection is not properly encrypted and authenticated.
I'm writing a GWT application, and I've been asked to implement the user management portion of the website. I know a little bit about salting, hashing, encrypting, and user tokens, but I've never read any books or studied papers on the subject.
I'm planning on doing a stateless implementation which means keeping user identifiers and submitting them to the server on every request. No server-side session data will be used. I'm looking at Apache Shiro, and I like the low level of integration so that I don't need to hook up to complex frameworks.
My biggest concern is with having a user token that doesn't expire. If I give them a token and they never log off, then I want the token to persist and be valid so that they can leave the web browser open overnight, and not have any session problems.
Does this plan leave the site vulnerable?
There is always some state that you'll have to keep on the servers if you want to perform any kind of user login. The only question is: Where does that state reside?
In the application server or
In the database (or maybe some other storage)
Obviously, the user name and password will be saved in the database. A session token is usually kept in the application server's memory - but it doesn't have to be. You could just as well save it in the database.
Because your implementation is stateless, with your current solution you'll have to retrieve the user name and password from the database for every request. You could easily change this to retrieve a token and timestamp instead. The only significant change is, that there may be multiple sessions per user, so you'll need a 1:N relation for users/tokens.
First:
If you want to write secure web pages read the OWASP Top Ten. This is comprehensive summary of most web applications vulnerabilities.
Second:
The main problem with your solution is the expiriation time of that token. If attacker will find out its value he will be able to impersonate real user for a long time. Also it is vulnerable for a brute force attack, when attacker will try to guess a token value. It would be wise to ask the real user for a password once in a few days and then change the token value.
I'm planning on doing a stateless
implementation which means keeping
user identifiers and submitting them
to the server on every request. No
server-side session data will be used.
I'm looking at Apache Shiro, and I
like the low level of integration so
that I don't need to hook up to
complex frameworks.
What happens when I copy someone's cookie?
What happens when I decipher the identifier and change it? (is it a int value?)
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.