Information Security Stack Exchange is a question and answer site for information security professionals. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I am currently coding the backend of a website and I have not come across an article where this is discussed. I want to store all my application data in MongoDB but I'd like to split out my sensitive user information into a MySQL database. My rational is that the MySQL database will only be accessed for authentication but I'd like to store usernames and passwords in a datbase that is ACID. The added benefit is that the user's data is physically separated from the user entity itself, which I like.

My question is, is this necessary? Should I keep all my data in MongoDB?

share|improve this question
up vote 4 down vote accepted

If you think the database engine you're planning to use isn't secure enough, then I wouldn't advise using it for anything. If it is secure enough, then the added complexity of two different database APIs will make your life harder, and not really affect an attacker (they'll just dump it to a file anyway).

If you want the data physically separate, you could put the password database on a separate machine from your other data.

If you correctly hash your passwords (PBKDF2, bcrypt or scrypt; high cost/iteration count), then your password database shouldn't be very useful to attackers anyway, except in the case of stupidly weak passwords.

Regarding ACID compliance: MongoDB does have atomic operations, it just doesn't have multi-document transactions, which presumably you don't need in a database that only has one collection.

share|improve this answer
Thanks. That makes sense. – MikeG Sep 13 '12 at 13:35

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.