how to make passport.js local strategy as secure as possible? - node.js

i'm trying to implement a login system with username/email in passport.js, i have read online that the local strategy is generally not secure, but after searching online i couldn't find any resource that could help me make it more secure.
i'm not sure if this's even possible, but i thought maybe i could use two strategies to work together, i thought that might give my application more security, like use local strategy with cookie strategy together for example, is this approach possible? if so, does it provide extra security and how do i implement the two together?
if such thing is not the best idea, how do i make authentication with local strategy a secure option? i'm planning on implementing other strategies like passport-google-oauth and such, but right now i want to include the username/email login in my application nonetheless, any help is appreciated, thanks in advance.

Related

How secure a user id with Golang Gorilla toolkit to be used with respect to sessions and secure cookies

I have started to look at Gorilla Toolkit for Golang but I am having some difficulty in understanding of to use sessions or securecookies? I want to produce a secure user id which I can move between server and client so I initially thought I would use sessions but I cant see how to plug securecookie into it, without securecookie the sessions just perform base64 encoding?
I am sure I have missed something but to be honest I have done a lot of Googling but the examples I have seen are typically showing how to use sessions or securecookie but not sessions which are secure? Or do I just use cookies and forget sessions?
Again sorry if I have missed something simple but I would just appreciate a point in the right direction on which of the toolkit parts are to be used together a simple example would also be very appreciated.
Many thanks in advance for your time.

Nodejs Do I need to use Passport

Alright, so I'm currently coding a Web Application with Node.js, and I'm a bit stuck on how I should handle user logins/authentication.
Lots of tutorials seem to recommend using Passport for your authentication, but from all the documentation I've read, it seems to take a bit of setting up and it complicates the simple login I was expecting.
Whether or not I use Passport, I still plan on hashing my user passwords that are stored in the Mongo database.
So the question is, do I need to use Passport for security reasons, or can I just code an authentication system my self?
It's really up to you, if you don't need Facebook, Google, or Twitter logins or are fine coding your own, I would just build it from scratch.
I built an application that didn't need all the bells and whistles that Passport came with, but needed it's own security built in, and found it much easier to just make my own. It's so easy to include your security as middleware in node!
I think it depends your use.Generally set a password is necessary, and use passport is not complicated in Nodejs .Of course ,if your application is used in internal,password can be ignored.But I think security is provided.

Passport.js practical for simple login

I'm designing my user authentication system using Node.js/Express, and as I've been searching the web for authentication strategies, I noticed that a lot of developers recommend passport.js for helping with authentication.
My authentication will only ever use a username/password strategy with JSON web tokens. Under that assumption, it seems like I have to manage the entire authentication myself: I check the username and password against the database, and I check and attach JWTs. It seems like Passport only wraps my work inside it's own functions.
With only a username/password strategy, what use is Passport? What does Passport provide in this scenario that is of any real benefit over me just performing the authentication without it?
Passport give you more flexibility and scalability. Now, you need one specific strategy, but in future you can add additional or remove old one. Using modules like passport you cause that your application code is independent of some processes. It is almost like dependency injection, you inject strategy in opposite to hardcode this.
I thing, that good application should have as much as possible functions/modules, that allow to inject polices/strategies. Separate modules is also nodejs/express style.
If you code your authentication in same style, then it is super (but why reinventing the wheel).
Using passport you can inherit from base Strategy and create new one strictly for your needs and use it with other strategies.
Never. Ever. Implement. Your. Own. Security. Framework
Unless you actually want to implement a framework and you have all the resources in the world to do that, all the required knowledge and the key people ( like OWASP ) & etc etc.
Use existing lib for your project
Use a library, or a framework, that's open source and battle tested. Yes it will not be perfect and will have limitations. Yes it may not be the most secure code ever. BUT it will be much better than your own, especially if you're starting from scratch.
Then follow best practices for CSRF, XSS, DDoS & other kind of attack prevention.

REST / Web based authentication-as-a-service a possibility?

I've developped a REST based service using Express and initially started implementing authentication myself. A simple username/password authentication where
passwords are encrypted using BCrypt
user info + hashed passwords are stored in a mongoDB
password verification checks are done.
authentication tokens (limited TTL) are generated / validated
I have some knowledge on Node.JS, but not nearly sufficient to make me feel comfortable about rolling out my own authentication (login/signup) mechanism.
For that reason I would like to replace my in-house mechanism with something else.
Something proven, extendable, pluggable and easy to use.
Given the amount of secure websites / REST APIs out there based on Node.JS, I'm sure there are out-of-the box solutions that people / companies have to offer that can get service implementors up and running very quickly, without having to worry about the security/user aspect.
I'm looking for an even higher level of abstraction than that of libraries like passport or everyauth. Something that provides out-of-the-box functionality, capable of fulfilling my requirements including :
providing a login page / signup page / profile page
different authentication modules (google,facebook,github,....)
storing user info (+credentials if required) in a datastore (mongoDB).
remember me
forgot password / reset password
So the question here is :
Are there out-of-the-box solutions like that available that offer a higher level of abstraction than passport/everyauth/... ?
If any, would you recommend some of these out-the-box solutions ?
Should I instead forget about the notion of outsourcing my user authentication and just start looking at passport and everyauth and start implementing my requirements using those libraries ?
Is it possible to focus on my business logic and not worry at all about any aspect regarding user authentication (writing login / signup pages , implementing forgot password / reset password flows, storing user info in the DB).
The service API should largely live independent of your authentication mechanism, so I'd recommend starting this behind a simple password protected folder or some such. In my opinion it would be better to make sure you're API works and can gain traction. Meaning it'll be more a long term project. Nothing kills a project quicker than focusing on the painful stuff right out of the box.
As far as what service to use? It's non-trivial to setup security well. So for a small startup project, it's probably more cost-effective to integrate with another service. Might take a look at Mozilla Persona. It's built on Node and pretty straight forward.
If you do try to roll your own get some outside expertise, and DON'T do stupid stuff like use a hashing algorithm like SHA1 to store passwords. Instead use something like bcrypt. Then there are other things like, don't store server logs on the server they're created. Pipe out all logs elsewhere so if there's an intrusion you have a forensics trail back to what happened.
I guess you could use https://stormpath.com/ . I'm looking for a free alternative myself..

What is the best login design for web applications?

First, let's define "best" here. The "best" login design/flow/algorithm/technique for the purposes of this question should be:
Simple. I don't think I need to explain why a simple system is better than a complicated one. OAuth 2, for example, is a very complicated system in my view. It defines, if I recall correctly, no less than nine different flows for granting an application access to a person's data. I find this superfluous, but that's not up for debate here.
Language-agnostic. Please do not answer by giving an implementation. I don't want an implementation. I want a design (or several...). You can give examples, but the solution you propose should be easy to code in any (read: most) language without requiring significant workarounds for features that aren't there.
Secure. The design should cover most common security problems on the net. XSS, CSRF, etc etc etc. I think a good set would be obtainable by going to Coding Horror and searching for "security"...
Now for some smaller details:
JavaScript is allowed. If a design can fall back to noscript environments, cool. But it's not a requirement.
Flash, Java applets are not allowed. This goes against the language-agnostic clause above: if your design requires something that is only available through Flash or Java, it's a flaw.
Password storage. There's a whole class of problems related to password storage. I don't want to hear about it.
Password transmission. This is important. Transmitting a password in plain is just plain evil. Over SSL, it might be acceptable, but if you can have a system that is (relatively) secure without relying onto end-to-end encryption, it would be awesome.
Given all this, propose the "best" user/login/logout design/flow/algorithm/technique you think fits the conditions outlined above. Or tell me if you think it's a fool's errand! ;)
I think you have already given some thought to this question. Easiest way to look at the solution is to break it in to different layers.
1) Database
Protected against sql injection. Just use prepared statements. Best and most secure!
Always and I mean always, make sure the db user has only the access privileges it needs.
2) Application
Use HTTPS. Don't even try to use anything else
Don't store user-id in the cookie or anything. Use session's if you must
If you don't have a session, generate a random id use that to look up a user. It's important to not have the cookie id not predictable.
3) HTML/Javascript
Protect against CSRF by doing a token system. This is the only legit way
Escape all you user input and sanitize it before writing to stream. In JSP, for example <c:out/> should be used
Don't do anything secure in javascript. This is an obvious answer but sometimes it good to remind
4) Etc
Keep patches up to date
Don't recreate the wheel. In Rails, there are already some excellent authorization gems. Use them!
I think out all of these, using SSL is the most important. You can create the most complicated system to do a double submit with an awesome encyrption algorithm. But with all of that, at the end, you still won't have a system that is more secure and better tested than SSL.
Interesting question.
I would consider:
When required I think web content should be public. So, as a user, I think it's best to have login only when it is required
SSO We should have mechanism to cross connect web applications more easily. I know that applications do not implement permissions the same way and we can't go wild there. That's where OAuth is filling the gap.
Do not use CAPTCHA (it is considered inaccessible). Unless you use something similar, like these
csrf hidden field to make sure that the form that are submitting is a valid one and not a random post to an endpoint
Always use SSL the big guys is doing it and it's unsafe to let our users send their passwords in clear text. Some proved it.
Always plan for without javascript Just in case, anyway it's not because we can do it that it's good to do.
That's my timeout for tonight. :)

Resources