How do you store sensitive data in mongodb


#1

Here is a use case:

User stores their credentials to a third party service so that the meteor app can call on that service on scheduled basis and do some logic in the background.

What are the best practices (security - wise) for storing these credentials?


#2

It depends heavily on the third party service.
Usually services that give you API access will supply you with a token or cookie that will allow you to make repeated calls to a service. When you need a users credentials to get this token, you often have to have the user visit the other site either manually or though a pop up in order to get the token.
This is essentially what happens with the third party login services like google or facebook login.
If you provide more details on what the credentials actually are, I can provide more advice.

P.S. on the off chance you are asking how to store a users password to a service you don’t directly control, the short answer is you shouldn’t
There is no way to do this securely, however if you absolutely must do so, ensure that the password for the service is encrypted before being stored in the database and the key stored on some other secure system. This won’t protect you against online attacks, but if you database is compromised and downloaded, then it offers some protection.


Store 3rd party password save for repeated access by back-end only
#3

This is very concerning. I need those credentials to be in the app without users having to punch them in to make things happen. Credentials are a username/pass combo for a third party API that should be called once a day to sync up the data. The API offers x509 authentication as well, but I don’t see how that would help me in this case.

There really isn’t a clear solution here it seems. If somebody got access to the server, they could just listen for the passwords being entered even if I had users come in to punch in the passwords. It would be nearly as safe to just store all these credentials into a settings file on the server because if someone broke in there, the show is over anyway.

Or I could go cave man, and just run the service myself from home manually once a day :confused:


#4

Maybe I misunderstood, are you talking about a single set of credentials to a third party service or does each user have their own set of credentials?


#5

Sorry this is an unusual case and I should have clarified it. There will be relatively few users of this kind, dozens or if I win lottery a few hundred. Low enough number where I could manually manage the credentials even if I had to key them in myself into a settings file.


#6

It really depends on your security requirements as well as the particular set up you need.

  • Whether its a public facing app or a back end service, i.e. whether it faces the internet
  • What sort of damage an attacker could do if they got access to the passwords
  • Whether the users know to not use the same password for login for your site vs the third party service
  • What particular x509 auth methods the third party service offers
  • If the user understands that they are giving you full access to the other service.

If the front end if public facing for example, I would keep the user/pass stored on another server than is update only (so a user can only update their username and password, not read it) and have the other server run the service call and then update your front end server. At least that way if your Meteor/Mongo server is compromised you minimise exposure.


#7

Thank you very much for chiming in so far.

I can minimize the potential danger quite a bit from what I see but being a paranoid type of person it bugs me very much that there isn’t really THE WAY to do this “right”.

I don’t have to worry about users needing access to enter or read the credentials at all. If needed I can get them over the phone and punch them in myself no matter how silly that seems.
Also, I can protect the users by setting up their third party service to only accept requests via those credentials if they come from my servers IP address.
I can even make the users use a truly randomly generated password as potentially I could be the one either setting this up, or telling them how to set up the passwords.

All of that amounts to “pretty ok” I guess, but the fact that someone who gets access to the server could still cause issues no matter what is what bugs me. No such thing as 100% safe on the interwebs