It seems to me that the last couple of years have created some fresh interest in database technology.
Nearly every company that I have talked to in the last six months has been considering NoSQL alternatives in many of their business applications. NoSQL includes all types of databases that don’t necessarily follow the relational form.
Dozens of videos on InfoQ, numerous presentations on SlideShare and endless posts on YC discuss how small and large businesses can apply NoSQL, replacing traditional relational database management systems (RDBMS). I see teams map-reducing mass amounts of sensitive data for analysis in Hadoop.
The buzz about the MongoDB outage at FourSquare got nearly as much attention from the world as the security breaches of traditional RDBMS at Gawker and Silverpop. I believe it’s all going to change soon: TeamSHATTER has seen strong growth in research and hacker activity targeting NoSQL databases.
This is an alarming trend and I predict that in 2011 we’re going to read about several high profile data breaches that involve NoSQL databases. There are some common trends in how companies, small and large, introduce these databases.
The start-up world usually assumes that the firewall or the Web application security prevents breaches. MongoDB, a popular choice for start-ups, explains the security documentation:

“One valid way to run the Mongo database is in a trusted environment, with no security and authentication (much like how one would use, say, memcached). Of course, in such a configuration, one must be sure only trusted machines can access database TCP ports.”

Furthermore, MongoDB documentation recommends an unsecure setup.
If you’re storing sensitive data of any kind, even e-mail addresses, don’t make this mistake. Software running behind a firewall with questionable security enabled Albert Gonzalez to execute the largest data theft in history.
Common sense should tell us that we cannot be storing sensitive data in any type of storage that is protected by the network alone. It’s not acceptable for traditional RDBMS, so it shouldn’t be acceptable for any other remote storage, including NoSQL.
The so-called “trusted environment” mode must not exist and, as much as I am a fan of MongoDB, should not be allowed in any database. MongoDB currently does support some basic authentication:

“The current version of Mongo supports only very basic security. One authenticates a username and password in the context of a particular database. Once authenticated, a normal user has full read and write access to the database in question while a read only user only has read access.”

This is a great start, but yields three familiar attack vectors. The first one is that any authenticated connection to the database gives an attacker access to all of the data. But unlike traditional RDBMS, NoSQL databases do not have a schema. Hence, segregating permissions on a schema, table, column or row makes no sense.
Therefore, you must be very careful about what you put in such a database and who can read or write it. Unfortunately, the majority of implementations that I have seen follow the traditional route of developing web applications and protecting data at the application level.
Developers build a RESTful interface on top of a database in Ruby on Rails, Groovy on Grails or Scala and Lift and segregate permissions rather high in this stack, mostly in routing, as illustrated below. The best you can do when developing such systems is to make sure to build the simplest possible interface with security from day one and user-facing applications on top of it.
But personally, I wouldn’t trust any web application to be the last line of defense for any valuable data.
The second attack vector involves passwords. Passwords are, by design, weak. They are stored clear or encrypted with a key that must be available to the application connecting to the database. This problem has been resolved in numerous software and hardware implementations.
My favorite is the Windows + MSSQL Server approach, where the operating system has a built-in mechanism to run services as authenticated users and delegate authentication using Kerberos or NTLM. In the Windows world we recommend disabling SQL Server (password) authentication altogether.
We are just now starting to see Kerberos authentication in NoSQL databases (Yahoo has recently contributed a Kerberos-based module to Hadoop).
The third vector exposes unencrypted communication with the database. To access a MongoDB instance, an MD5 scheme is employed to send a password a hash over the wire (see mongo_pass_digest in mongo.c). This can be stolen, replayed or attacked via a rainbow table.
To conclude, NoSQL is gaining popularity at a rapid pace for modern applications, primarily on the web. The databases are often free, perform beautifully and improve developer productivity.
But before you switch, evaluate your risks. Consider the very serious security implications and dedicated time and people needed to manage and understand the security aspects of these new systems.
While we know how to secure data in traditional RDBMS, we’re just learning about how to do it in NoSQL databases. And even if you’re storing user’s e-mail addresses and (likely reversible) password hashes, the loss of reputation resulting from a data breach could cost you your business.
Finally, many of the new NoSQL databases are open-source. If you employ developers, consider contributing stronger authentication and authorization implementations to your favorite NoSQL database system. For MongoDB, I’d like to see a solid implementation forSERVER-524: Encryption/Compression of wire protocol and SERVER-2360: Add a stronger password authentication scheme.

Source: infosecisland.com