1

is my stack secure on mongodb if i use mongos out-of-box username/password and roles for generating tokens, and I do not personally attempt to come up with a salt+hash for usernames & passwords (by having a combination of local DB salts, external AWS salts, and hard-coded end-point salts)?

The stack: I am hosted on AWS with a pem file that allows SSH access.

My security groups only allow SSH from my ip address.

I have a load balancer that uses SSL and points to nginx, which points to node. Node forces all http traffic to redirect to https. and my database is mongo.

mongo does not require a username or password to query data.

the load balancer allows all HTTP and HTTPS traffic in and out. the EC2 only allows HTTP and HTTPS in from the loadbalancer.

I have public API end-points where I generate a token via login with a correct username & password.

I do not store the users password in the database, instead I hash using

crypto.createHmac('sha512', server_salt + user_salt)

where the user salt could be guessed by a combination of the users information in the database plus a hard coded string in my js script, but the server salt is not located in my database. it is located in an amazon service repo.

The database I have which houses active tokens for users does not expose the userID for each token, but instead again has a one-way hash. tokens expire every 24 hours. (If I performed collection level access restriction, then i would expose which user-id mapped to each token, but the collection would be restricted to only be accessed by the user him/herself, so it should be safe?)

token strings are generated on login using:

crypto.randomBytes(120,function(err,byte_token)

If a token is not valid for a user, i return 401.

If a user tries to access user information that does not belong to him I return 403.

Tokens expire every 24 hours, using mongos expireAfterSeconds https://docs.mongodb.com/manual/tutorial/expire-data/

Thoughts?

closed as too broad by Stephen Touset, Mark, Xander, Matthew, Dmitry Grigoryev Jan 26 '17 at 11:59

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 2
    This is composed of way too many sub-questions to be of any use to people in general. You don't specify who or what is in your threat model, and it's impossible for anyone to answer your question in a general sense. That said, please read up on how to hash a password. TL;DR, your salts are not actually performing the job of a salt, if you're not throttling requests attackers can brute force passwords remotely, and you should use off the shelf password hashes like bcrypt, scrypt, or argon2. – Stephen Touset Jan 25 '17 at 23:44
  • 1
    There is at least one missing security measure in what you've described: "mongo does not require a username or password to query data". I recommend reviewing the MongoDB Security Checklist and taking appropriate measures such as enabling authentication, configuring role-based access control using Principle of least privilege, restricting network access via firewalls, and encrypting network communication between your application and database servers. – Stennie Jan 26 '17 at 11:23
  • Thanks @Stennie. So if i use mongodbs out-of-box username/password then i dont really need to worry about hashing passwords. So if i wanted to use security tokens (so users are not sending username/password to each end-point, but rather a token), I could have a collection for each user-id that has one record (which is the active security token for that user?) and then make sure that only the user has read-write access to their own collection? docs.mongodb.com/manual/core/collection-level-access-control – user1709076 Jan 29 '17 at 20:07
  • The edited question is still very broad, and you are now conflating the security of your API with the security of your MongoDB deployment. End users of your API should not be connecting directly to MongoDB, and your API security model is independent of the underlying MongoDB users and permissions. – Stennie Jan 30 '17 at 0:17
  • For communication between your application and MongoDB, the MongoDB Security Checklist has links to relevant tutorials. To securely store passwords for your API, you should read the How to securely hash passwords question suggested by an earlier commenter. In addition to password security for your API , you need to consider other aspects such as brute force mitigation and auditing of your application logic for possible errors. – Stennie Jan 30 '17 at 0:17

Browse other questions tagged or ask your own question.