Just have some general questions about the level of security one can expect when using passport for an App's Authentication;
I am currently in the process of designing my first App using a MongoDB, Express, React and Node.js stack. Without having much prior knowledge about cyber security I have done quite a bit of research about authentication and what type of attacks can occur on my site. I have opted to use a cookie-based authentication system with the passport.js npm package and I have designed my /login route to require that the user's password and username first pass a passport.authenticate('local', ....) middleware setup before a session and cookie are created.
In order to persist the current user in my react app, I have a function which requests the server to provide it with the currently active passport session if there is one - and this seems to work as it will not maintain a login state if the user deletes the session cookie from their browser.
I am a bit skeptical of passport and I'm curious to know how easily it could be breached by someone who has a higher understanding of how it works, so the things I am wondering are several:
Is this type of authentication setup secure?
Are there any additional requirements that one must implement in order for passport to be a
legitimate method of authentication for an App?
Is using passport to authenticate users considered to be bad practice? Would showcasing an app that
authenticates users by using an npm package look bad if I were to showcase this application to a
potential employer?
I can share code if necessary to better illustrate my code setup, although I would prefer not to if at all possible. Any advice would be much appreciated, thanks!
TLDR:
Is passport.js a secure method to authenticate users? Is using passport.js for this bad practice?
Passport.js provides authentication, not security. It is fairly easy to misconfigure by following online tutorials, so take care - the tool is only as good as the hand it is in. To add security to passport, you will need at the very least three additional elements:
Strong state model for the session (or token) that does not leak private fields and uses argon2 for password hashing.
No mistakes on the front-end with CSRF or XSS.
Rate and buffer limitters on Node itself or, even better, on your reverse proxy.
Related
I'm writing my first Express NodeJS app and I want to know what is the best practice when it comes to authentication middlewares?
I'm using access tokens and cookies (which are composed from user id and some random bytes) for each new user, and for some routes I want only given users to have access to it.
Is a good idea to access database from a middleware? Or where should I check if a given user has access to a given resource?
Thank you!
There are many modules built for authentication purpose for nodejs applications. However, the most commonly used module for nodejs/expressjs is Passport. If you wish to stay isolated from such libraries, nodejs has built-in libraries for encryption etc, for example, check this out.
For sessions and cookies, using signed cookies is always a good practice. Check out this SO post. There are many good practices for maintaining security (say, using https over http, token based authentication, etc.) followed throughout the development grounds, which you'll learn as you go on. Here is a short tutorial of JWT(JSON Web Tokens) for a good introduction to token based authentication in JSON you can check out.
Happy coding :)
I'm developing my web-site project based on NodeJs/Express, and for some UI parts I'm using Jquery ajax request to fetch secondary data.
How can we handle some basic control on our Rest API end-points that are used for ajax calls by the browser?
I was thinking about some kind of token authorization , but it can be also used by other clients (scripts etc.) once it has been intercepted , so how can we protect our server from unwanted requests? What other controls should be used in this cases (recognize too many request from same client, clients black list,etc)?
There are three main topics Authentication, Authorization, Security. I will give links and only shortly answers. Subject is enough big to write few books.
Authentication - who is the one who is making request. There are many 'strategies' to authentication user. Please check most pupular module for this : http://passportjs.org/docs.
Of course you can inplement one or more of this strategies alone.
For stateless authentication jwt tokens are very convenient. If you want to code it yourself (Passport has this strategy) check this link (one of many in web) https://scotch.io/tutorials/authenticate-a-node-js-api-with-json-web-tokens.
How to prevent from token interception? Use always https and set token expiration time short.
Where to store your token client side? for detail look at this https://stormpath.com/blog/where-to-store-your-jwts-cookies-vs-html5-web-storage/ In short don't store in web storage because of XSS attacks. Use cookies, when they are correctly configured they are safe (more in attached link), if not configured they are very exposed to threats.
Authorization : we know user, but he has access only to some resources. Please check https://github.com/OptimalBits/node_acl
There is gist with node_acl and passport : https://gist.github.com/danwit/e0a7c5ad57c9ce5659d2
In short passport authenticate user. We now who want what. We setup roles and resources and define roles and resources relation. Then we set for each user roles. Module will check for us user permission.
Security: please look for this subject in documentation of sails framework http://sailsjs.org/documentation/concepts/security they describes attacks and how framework prevent form them. I write about express:
DDOS: (part of your question "too many request from same client") "At the API layer, there isn't much that can be done in the way of prevention". This is subject most for servers admins. In short use load balancer. If it is one IP (not hundreds) then blacklist or deley response (for start look at this https://www.npmjs.com/package/delayed-request but I thing that solution must be more sophisticated).
CSRF: "type of attack which forces an end user to execute unwanted actions on a web application backend". Look at this module https://www.npmjs.com/package/csrf
XSS: "type of attack in which a malicious agent manages to inject client-side JavaScript into your website" don't trust any data from user. Always validate, filter, santize. Look at this https://www.npmjs.com/package/xss
In documentation of sails, there is more attack types but above are most popular.
Use express session + passport (http://passportjs.org/)
Basically you should have a login to the website and than only authenticated users can call the REST apis.
now... if you don't want a login, than you can't really protect the APIs as the website by design is open.
You didn't specify much info so it is hard to say more than that.
Also DoS attacks can't be protected by your code, and usually its not the responsibility of the app server (in your case node.js express) to provide such protection. If someone wants your website down by doing DoS attacks, than without other layers (see https://en.wikipedia.org/wiki/Denial-of-service_attack#Defense_techniques) which mostly mean it is up to a router/switch/so on... to implement.
I'm tackling the design of my first API and am struggling somewhat with authorisation concepts - I was hoping some kind people could give me some advice!
What I'm building:
An API that will eventually be accessed by third party apps and a mobile app.
A web-based 'client' (first-party single page app) that will use the API. (Should this first-party app be 'a part' of the API, or a completely separate node app?)
Technology I plan to use:
Node
Express
Passport
Mongodb with Mongoose
I'm not wed to express or passport, they just seem like the best options and are well documented - bit I wouldn't want a potential solution to be dismissed because of alternative dependencies. Same with Mongoose, I actually prefer the look of Monk (or even just Mongojs), but every tut seems to use mongoose, so seems like the safest option for a node beginner.
Authenticating a user is simple enough (I've gone through the fantastic Beer Locker tutorial), what I'm struggling with is ongoing authorisation. Naturally I don't want the user to have to input a username and password with every request they make - should this information be stored locally and sent with every request? (if so, how? I can't find any info on handling an API with a session) or should I be working with tokens of some sort? The small amount of reading I did on 'Digest' authorisation (including the Beer Locker tutorial follow-up) made it seem like it had security issues, at least with the Passport implementation (this I don't fully understand, but seems to relate to hashing passwords, which passport doesn't do as standard, and only MD5 is supported even if it's added?).
I have built a working API that I can authorise with 'Basic' (directly, through Postman), so I have the foundations in place - authorisation works, I just need the tools to take that to the next step and add sessions into the mix!
I've been trying to get my head around this for a couple of days now, but I fear I'm too stuck in a more traditional local web-app workflow - the whole API thing is throwing me somewhat.
Any help is hugely appreciated, even if it's just pointing me at an appropriate tutorial - the above set of requirements must be quite common!
I have come accross this problem too...
I can only recommend doing this for the beginning:
http://scotch.io/tutorials/javascript/easy-node-authentication-setup-and-local
tell me if it helped :)
As I understand you have done the authentication and the only thing you have to do now is store somewhere that the current user is authenticated, his name, roles etc to use later with other requests. In the Passport you will do it in the function callback (instead of the "If this function gets called..." comment).
Now you have to decide, you have two options:
Store the user information (name, roles etc.) on your server (in a session) and give the user some long code which will identify his session for the next requests
to store the information on your server you may use for example the express-session middleware
it would be probably best to save the session identifier in a cookie, but read some security issues before
Give the user something that would prove to you he/she is authenticated and which name, roles etc. he/she has
you can generate a token, that contains the user information (name, roles etc.) that the user will send with every request. to know this token is legit, you will have to sign it. more on this is on jwt.io and you can use express-jwt middleware.
you dont have to care about storage of session with this one
the token can be placed to a cookie too, but same security issues apply. it is still considered better that localstorage (more here)
I'm new to Node, Passport and authentication in web development in general
I followed this tutorial for setting up local authentication using the Passport module.
I was hoping an experienced developer could comment on the security of the design being taught there.
More specifically,
1) When the author does a POST for sending credentials, shouldn't he be doing it over HTTPS? When is it necessary to use HTTPS so that others aren't sniffing your information? How could the design be changed to POST using HTTPS?
2) I can't follow how session is being kept track of. Does passport abstract all of the session work? If so, are they using cookies? Are the cookies plaintext? Does the user get a token back in a cookie? Is that how isLoggedIn() works?
3) Is he getting any protection from content injection for free? I don't see any code to try and escape dangerous characters or anything.
Anyway, how hacker safe is this design?
I have several questions:
1) Is it a good practice to use REST API both for external API usage and as a server side for a backbone (or plain js) frontend?
I think it's much easier to code one REST API server and use it as a backend.
2) If I write my webapp authentication with oauth 2 standard is it a good way to store my secret token in cookie? I think this will cause CSRF vulnerability.
As i see passport.js uses cookies to store secret token for example for Facebook or twitter...
What's about CSRF in this case?
This is a very interesting question, I'm surprised nobody answered yet.
1) To the first question, my answer is definitely yes ! You don't want to write 2 times the API logic.
What you could do is to use different URLs.
Eg. For the public api, you use http://api.domain.com/objects/ whereas concerning the internal one, you could use http://domain.com/api/objects/ or whatever you prefer.
Then you use the same logic, but with different authentication strategies. Public one with authentication token, like many popular APIs (Twitter, Facebook etc.) and Private one using passport.js's logs.
The good thing about separating is :
You separate security issues
You can control access bandwidth if your app transfers a lot of data (and you want to give a higher priority to you app ... well probably !)
Or simply you can control authorizations (Eg. no DELETE through public API)
2) I'm not a security guru, but I would definitely trust passport.js authentication system, as it is widely used when using node as a backend.
You could refer to this question for implementing CSRF security in express : How to implement CSRF protection in Ajax calls using express.js (looking for complete example)?
Or another strategy is to use a refresh token if you use FB or Twitter connect strategies.
Hope it helps.