CODEWITHSUNDEEP
node.jssecuritymongodbpasswords
shennan
shennan

Reputation: 11676

Should I go with MongoDB auth support or simply bolt on a more application-specific approach?

New to Node, new to Mongo. Etc Etc...

I'm itching to get started on a project with these two technologies but one of the concerns is security. It seems more terrifying with Node because the server logic is so close to the application, and MongoDB comes with flood-gates open right out of the box.

My question is, am I right in assuming that the only real use for MongoDB's native authentication support (i.e the system.users database) is in the event of needing to screen external connections from outside the server?

So, if I restricted the MongoDB instances to only accept connections through the localhost, would I just leave the authentication to my own application business logic? Or should I be going gun-ho, creating MongoDB documents in system.users for every tom-dick-and-harry that want to 'create an account' with my site?

Is there a middle ground?

For extra kudos, some tips on best practises for password storage in MongoDB would be useful...

Upvotes: 0

Views: 266

Answers (1)

Peter Lyons
Peter Lyons

Reputation: 146114

am I right in assuming that the only real use for MongoDB's native authentication support (i.e the system.users database) is in the event of needing to screen external connections from outside the server?

Yes, essentially.

should I be going gun-ho, creating MongoDB documents in system.users for every tom-dick-and-harry that want to 'create an account' with my site?

So database applications almost never give each end user a database account, and for good reason. End users don't want nor need a full database account. That's why you have an application - to give the users custom-tailored functionality. Also, generally you want to support a large number of active end users but you only want a small handful of active database connections. Finally, almost every application has complicated authorization logic that controls which users can read or write which bits of data that the database itself cannot enforce. So typically you can either:

A) Have mongo bind to loopback and accept anonymous connections

or

B) Create a mongo user that represents your entire application and have the handful of connections from your app server(s) to the database authenticated with these credentials

Both approaches are common and honestly the deployment simplicity of A) frees up some security mind space to focus on more likely vulnerabilities like XSS and so forth.

To summarize:

  • loopback without authentication: OK
  • loopback with 1 application user: OK
  • public IP without authentication: FAIL
  • public IP with authentication but no SSL: FAIL
  • public IP with authentication and SSL: OK

To store end user password hashes in mongo, use bcrypt. This is widely documented so I'm not going to reproduce that here for you.

Upvotes: 2

Related Questions