6 ms·

Why NoSQL Equals NoSecurity

27 points by jordhy 15y ago

jedberg 15y ago
This article makes it sound like relational databases are the pinacle of security. Sure, they have usernames and passwords and other controls, but the data is still usually stored unencrypted. I don't think putting a few username/password credentials onto the datastore will make it much more secure, especially if I can put those same access controls into a database access layer. In the end you need to defense in depth just like always, and that includes putting access controls, network controls, OS controls and everything else.
- ks 15y ago
  I haven't tried it myself, but Redis has support for simple authentication at least. http://redis.io/topics/security http://redis.io/topics/security
  - ZephyrP 15y ago
    Just in case you want to open up your Redis instance to the internet? Sometimes I think people like antirez add these features just so an article isn't published proclaiming Redis security to be broken because of no password authentication.
  - NyxWulf 15y ago
    We use the authentication in our apps. It's simple, and as Zephyr suggested I wouldn't recommend using that as your only security - it's not our only security, just part of the overall approach.
NyxWulf 15y ago
We use hadoop, cassandra, and redis in production. I've never found Information Week to be a high quality source of information, and unfortunately this is no exception. Data systems almost always rely on being in segmented and protected portions of a network with access being controlled by applications and firewalls. Overall this article struck me as having an axe to grind. I wouldn't put, SQL Server, Oracle, MySQL or any other database on the web with open access. Just like we don't do that with any of our NoSQL solutions. Generally, I've found that security granularity is not as robust in the newer Big Data tools, but that was the same argument against MySQL and Postgres a decade ago. * Edit: Since we are playing on names, apparently Information Week = Information Weak.
protomyth 15y ago
Sybase and Oracle do have pretty good security solution when you dive deep into them, but I gotta question the whole premise of the article. I have always believed if a outsider can get to your database / datastore then you already have a ton of problems.
haldean 15y ago
The article doesn't make it clear what sort of security features the author would like to see in NoSQL databases beyond SSL support, which they then admit is offered by MongoDB's "commercial offering". Never mind that the commercial version is, I'm assuming, the one that is used by all of the financial institutions the author is worried about. I'm curious though -- what security features (if any) does HN think NoSQL DBs are missing?
- hughw 15y ago
  Exactly -- for his example of a financial services system, just buy the commercial version, or tunnel using ssh. You can also encrypt the underlying file system using your OS's tools. I can't speak to how financial institutions use, say, Oracle's authentication and authorization. Most web apps & services use their own logic to manage access control. I'd love to hear what someone form that industry has to say. (An "architect" preferably. Not a mere "developer", who are the cause of this whole security problem ;) ).
ZephyrP 15y ago
I'm the author of a (very) new NoSQL datastore called Artifact (http://zv.github.com/artifact/ http://zv.github.com/artifact/), that, admittedly, is very prototypical and is not representative of MongoDB, Couch, Riak or any of the other major players. I'm also a vulnerability researcher who makes his way in the world finding and dissecting security bugs and holes in network infrastructure. I feel this article misrepresents a lot of facts about security in the same way that articles discussing the relative security of passwords misrepresent security. Here's what I mean Question: Whats the most obvious way to attack a system? Answer: Guess Passwords. Because this is the most obvious way to attack computer systems, an undue amount of attention is paid to the topic because it's the only way we're aware of. In reality the vast majority of systems compromised happen because of memory corruption vulnerabilities, or in recent years, (predominantly) web bugs like SQLi and LFI. Explaining the dynamics of taking control of a program through smashing the stack and getting EIP is tough, at least in contrast to explaining how guessing passwords works. So people worry that "their passwords aren't secure" despite that any real black hat deleted D8.dic off their harddrive years ago. Thus, theres a million articles and sites on how secure your password is, but not that many to check if you've got address randomization enabled. Are Blackhats trying to read your NoSQL stores after staging an internal attack? Possibly, but not nearly as likely as the fact that you've got xp_cmdshell enabled. Attacking MongoDB is tractable, and provides numerous opportunities for a wide nop sled w/ memory mapped files and more than enough opportunity for use-after-free attacks in objects, but the same (and then some!) can be said of any modern SQL database. The fact that query strings are safe in every major NoSQL datastore is such a massive advantage over SQL DBs that, even if you're using prepared statements, NoSQL is almost assuredly more secure in a day to day context, except against zero-days (Which we can reasonably say are less frequent in established datastores, irrespective of their design decisions). The fact that he quasi-attacks stateful firewall security in the article is pretty much baseless, clever TCP bugs are long since worn out, and all the things that mainstream developers have thought is clever like firewalk(8) haven't been effective since I was 11. It's not unreasonable to trust major commercial firewalls for anything you'd trust SSH for. It's not reasonable to trust C/C++ applications in general, as even the most valorous efforts at secure software have turned up short (The beautiful irony here may be that SSH, as trusted as it is, has had numerous pre-auth exploits in it, as it is written in C++) Finally, let's be real, as an article aside -- SSL does absolutely nothing. Every single year there are multiple complete breaks in what SSL is supposed to do, both practical and theoretical. These complete breaks are regularly released with executables, so don't give me that "We're only raising the ba-" Nope, ASLR and W^X raise the bar, you could argue SSL widens your attack surface on anything but HTTP transactions. Furthermore, if MITM is the biggest thing you're worried about then I'd encourage you to download any of the latest XML parsing libraries or PDF readers to rectify that -- it's tragically only minor exaggeration to say attacking these complex, loosely interacting components such as parsers to stage a more complex internal attack is organizational computer hacking in 2012.
thezilch 15y ago
WTF? If you can't trust your network, OS, and user level access, how are you going to trust a DB ACL? I'll put everything up against Information Week using a caching layer (Re: memcached), which has unfettered access without security from an external layer. Non-NoSQL don't magically make security a non-issue; what a joke; in all cases, equally, one has to be aware and diligent about securing your network.
- nupark2 15y ago
  > WTF? If you can't trust your network, OS, and user level access ... You can't trust them all equally, and allow for a failure in any one of them to result in a total failure of all security. That's the M&M security model -- crunchy on the outside. This is one (of several reasons) I wouldn't use memcached without authentication if it could lead to a privilege increase: It completely breaks defense-in-depth. Compromise of just one system can lead to total system compromise.
  - thezilch 15y ago
    The article's author/etc simply has an axe to grind with NoSQL. Are we going to throw out our *nix flavors that have us disable root SSH? Our FSes that don't have or disable-by-default block encryption? Security should definitely be championed, full stop, but I'm not convinced by this article that NoSQL or relational DBs have any reason to be implementing the secure layers on my systems. A big draw to NoSQL is not only the ease of use. One advantage is the separation of working parts. Not jack of all trades, master of none architectures.
- shuzchen 15y ago
  Honestly, I don't think the ACL really provides much in terms of security. I mean, your db username and passwords are stored (in plain text) in your settings.py, config.php, database.yaml, etc. I've seen a few times where master passwords have shown up in a user's bash history due to carelessness. Also consider that your backup script contains read access credentials for all your data. IMO the main benefit of having an ACL is to compartmentalizes your database so that a SQL injection against one app (maybe) won't spill over to a different app. That's not something that makes me feel good at all.
count 15y ago
How much information from highly secured RDBMSs is leaked and lost on a daily basis? How much of that leakage is prevented by the database's security mechanism, vs. that of the application connecting to it? And to pick on certain things - does SSL connections REALLY matter? If you're running over an untrusted network (bad idea, in general), why not just use IPSEC?
methodin 15y ago
I would tend to think financial/banking/<insert would-be secure application here> would be insecure no matter what data store they use. It seems to just be part of the game - ask anyone that's developed for one. One would assume that by adopting NoSQL that would mean a refresh of code/architecture/security but only a small part of me actually believes that. I also do not really understand the point of this article ad it did not provide me with anything useful.
- NyxWulf 15y ago
  I'll play. I worked at a financial institution for several years. On the one hand you'd think we were secure because we used a relational database, but we also had a heavily segmented network with all of the databases in their own VLAN's with highly restrictive permissions. On top of that each application was locked down to exactly which data it could use and what could be done with that data. So if you buy the premise of the article, it wasn't NoSQL, so it must have been secure. In reality we were very secure from external breaches, at least as secure as you can reasonably be. Personal information was secured to the maximum extent possible. Encrypted, backed up to multiple independent tapes stored in separate locations etc. On the other hand, the overall complexity of the system was very high and if someone breached our network there would have been a very large surface area to attack. I didn't feel like the article addressed this aspect of security in the least. Security just isn't one of those things that are easy or are ever done. It takes constant vigilance and continuous adjustment and improvement.
  - methodin 15y ago
    Did your institution go the seldom traveled route of encrypting sensitive information? Typically all the effort is spent trying to avoid breaches instead of protecting against them when they occur.
    - NyxWulf 15y ago
      Initially it was not encrypted and was stored in plain text in the database. Then we started encrypting sensitive information at rest, both the database files and the backups. We also encrypted certain sensitive information with a secondary encryption. The next massive undertaking was to find all of the processes that use the data, how they use it - both internally and externally, and then ensure the data was protected throughout the entire process. The company was still working through that process when I left. They had identified many places that were problematic and were actively working on fixing them. The team I managed was the payment processing and cash management team. There were a number of legacy systems written in access, fox pro, DTS, Excel even. Many of those were the most painful, and frankly the most problematic. Many people were put in a situation where the requirements for getting something implemented through the IT teams would take months, yet they were still held accountable for getting things done, so they would build an Excel process to get the job done. They would build some fantastic process, and get promoted, then that Excel system would get dumped on either someone in IT or someone replacing them. I'm getting off track, but looking at it superficially the data was encrypted. If, however, you watch the data through it's entire value stream, there are many places it is vulnerable. Given the state of affairs in most companies and how few of them think in terms of managing value streams, I expect my observations are fairly widely applicable.
datasage 15y ago
RDBMS's, put a large focus on data integrity and access within the datastore layer itself (To differing degrees); NoSQL systems more or less offload that responsibility into the application layer. There is still a responsibility of running it within a trusted network. This is a decision that may not be appropriate for everyone, but that does not make it wrong. Many people who used mySQL to power web applications did use just one credential to access the database. In that scenario the authentication overhead is pretty much just a waste of time.
luca_garulli 15y ago
Seems like NoSQL target was to solve small part of your Big-Data problem. This is changing because NoSQL can replace RDBMS in many fields and Security is becoming a MUST to have too. AFAIK OrientDB is the only NoSQL supports security: http://code.google.com/p/orient/wiki/Security http://code.google.com/p/orient/wiki/Security.

27 points by jordhy 15y ago

This article makes it sound like relational databases are the pinacle of security. Sure, they have usernames and passwords and other controls, but the data is still usually stored unencrypted. I don't think putting a few username/password credentials onto the datastore will make it much more secure, especially if I can put those same access controls into a database access layer. In the end you need to defense in depth just like always, and that includes putting access controls, network controls, OS controls and everything else.

ks 15y ago
I haven't tried it myself, but Redis has support for simple authentication at least. http://redis.io/topics/security http://redis.io/topics/security
- ZephyrP 15y ago
  Just in case you want to open up your Redis instance to the internet? Sometimes I think people like antirez add these features just so an article isn't published proclaiming Redis security to be broken because of no password authentication.
- NyxWulf 15y ago
  We use the authentication in our apps. It's simple, and as Zephyr suggested I wouldn't recommend using that as your only security - it's not our only security, just part of the overall approach.

NyxWulf 15y ago

We use hadoop, cassandra, and redis in production. I've never found Information Week to be a high quality source of information, and unfortunately this is no exception. Data systems almost always rely on being in segmented and protected portions of a network with access being controlled by applications and firewalls. Overall this article struck me as having an axe to grind. I wouldn't put, SQL Server, Oracle, MySQL or any other database on the web with open access. Just like we don't do that with any of our NoSQL solutions. Generally, I've found that security granularity is not as robust in the newer Big Data tools, but that was the same argument against MySQL and Postgres a decade ago. * Edit: Since we are playing on names, apparently Information Week = Information Weak.

protomyth 15y ago

Sybase and Oracle do have pretty good security solution when you dive deep into them, but I gotta question the whole premise of the article. I have always believed if a outsider can get to your database / datastore then you already have a ton of problems.

haldean 15y ago

The article doesn't make it clear what sort of security features the author would like to see in NoSQL databases beyond SSL support, which they then admit is offered by MongoDB's "commercial offering". Never mind that the commercial version is, I'm assuming, the one that is used by all of the financial institutions the author is worried about. I'm curious though -- what security features (if any) does HN think NoSQL DBs are missing?

hughw 15y ago
Exactly -- for his example of a financial services system, just buy the commercial version, or tunnel using ssh. You can also encrypt the underlying file system using your OS's tools. I can't speak to how financial institutions use, say, Oracle's authentication and authorization. Most web apps & services use their own logic to manage access control. I'd love to hear what someone form that industry has to say. (An "architect" preferably. Not a mere "developer", who are the cause of this whole security problem ;) ).

ZephyrP 15y ago

I'm the author of a (very) new NoSQL datastore called Artifact (http://zv.github.com/artifact/ http://zv.github.com/artifact/), that, admittedly, is very prototypical and is not representative of MongoDB, Couch, Riak or any of the other major players. I'm also a vulnerability researcher who makes his way in the world finding and dissecting security bugs and holes in network infrastructure. I feel this article misrepresents a lot of facts about security in the same way that articles discussing the relative security of passwords misrepresent security. Here's what I mean Question: Whats the most obvious way to attack a system? Answer: Guess Passwords. Because this is the most obvious way to attack computer systems, an undue amount of attention is paid to the topic because it's the only way we're aware of. In reality the vast majority of systems compromised happen because of memory corruption vulnerabilities, or in recent years, (predominantly) web bugs like SQLi and LFI. Explaining the dynamics of taking control of a program through smashing the stack and getting EIP is tough, at least in contrast to explaining how guessing passwords works. So people worry that "their passwords aren't secure" despite that any real black hat deleted D8.dic off their harddrive years ago. Thus, theres a million articles and sites on how secure your password is, but not that many to check if you've got address randomization enabled. Are Blackhats trying to read your NoSQL stores after staging an internal attack? Possibly, but not nearly as likely as the fact that you've got xp_cmdshell enabled. Attacking MongoDB is tractable, and provides numerous opportunities for a wide nop sled w/ memory mapped files and more than enough opportunity for use-after-free attacks in objects, but the same (and then some!) can be said of any modern SQL database. The fact that query strings are safe in every major NoSQL datastore is such a massive advantage over SQL DBs that, even if you're using prepared statements, NoSQL is almost assuredly more secure in a day to day context, except against zero-days (Which we can reasonably say are less frequent in established datastores, irrespective of their design decisions). The fact that he quasi-attacks stateful firewall security in the article is pretty much baseless, clever TCP bugs are long since worn out, and all the things that mainstream developers have thought is clever like firewalk(8) haven't been effective since I was 11. It's not unreasonable to trust major commercial firewalls for anything you'd trust SSH for. It's not reasonable to trust C/C++ applications in general, as even the most valorous efforts at secure software have turned up short (The beautiful irony here may be that SSH, as trusted as it is, has had numerous pre-auth exploits in it, as it is written in C++) Finally, let's be real, as an article aside -- SSL does absolutely nothing. Every single year there are multiple complete breaks in what SSL is supposed to do, both practical and theoretical. These complete breaks are regularly released with executables, so don't give me that "We're only raising the ba-" Nope, ASLR and W^X raise the bar, you could argue SSL widens your attack surface on anything but HTTP transactions. Furthermore, if MITM is the biggest thing you're worried about then I'd encourage you to download any of the latest XML parsing libraries or PDF readers to rectify that -- it's tragically only minor exaggeration to say attacking these complex, loosely interacting components such as parsers to stage a more complex internal attack is organizational computer hacking in 2012.

thezilch 15y ago

WTF? If you can't trust your network, OS, and user level access, how are you going to trust a DB ACL? I'll put everything up against Information Week using a caching layer (Re: memcached), which has unfettered access without security from an external layer. Non-NoSQL don't magically make security a non-issue; what a joke; in all cases, equally, one has to be aware and diligent about securing your network.

nupark2 15y ago
> WTF? If you can't trust your network, OS, and user level access ... You can't trust them all equally, and allow for a failure in any one of them to result in a total failure of all security. That's the M&M security model -- crunchy on the outside. This is one (of several reasons) I wouldn't use memcached without authentication if it could lead to a privilege increase: It completely breaks defense-in-depth. Compromise of just one system can lead to total system compromise.
- thezilch 15y ago
  The article's author/etc simply has an axe to grind with NoSQL. Are we going to throw out our *nix flavors that have us disable root SSH? Our FSes that don't have or disable-by-default block encryption? Security should definitely be championed, full stop, but I'm not convinced by this article that NoSQL or relational DBs have any reason to be implementing the secure layers on my systems. A big draw to NoSQL is not only the ease of use. One advantage is the separation of working parts. Not jack of all trades, master of none architectures.
shuzchen 15y ago
Honestly, I don't think the ACL really provides much in terms of security. I mean, your db username and passwords are stored (in plain text) in your settings.py, config.php, database.yaml, etc. I've seen a few times where master passwords have shown up in a user's bash history due to carelessness. Also consider that your backup script contains read access credentials for all your data. IMO the main benefit of having an ACL is to compartmentalizes your database so that a SQL injection against one app (maybe) won't spill over to a different app. That's not something that makes me feel good at all.

count 15y ago

How much information from highly secured RDBMSs is leaked and lost on a daily basis? How much of that leakage is prevented by the database's security mechanism, vs. that of the application connecting to it? And to pick on certain things - does SSL connections REALLY matter? If you're running over an untrusted network (bad idea, in general), why not just use IPSEC?

methodin 15y ago

I would tend to think financial/banking/<insert would-be secure application here> would be insecure no matter what data store they use. It seems to just be part of the game - ask anyone that's developed for one. One would assume that by adopting NoSQL that would mean a refresh of code/architecture/security but only a small part of me actually believes that. I also do not really understand the point of this article ad it did not provide me with anything useful.

NyxWulf 15y ago
I'll play. I worked at a financial institution for several years. On the one hand you'd think we were secure because we used a relational database, but we also had a heavily segmented network with all of the databases in their own VLAN's with highly restrictive permissions. On top of that each application was locked down to exactly which data it could use and what could be done with that data. So if you buy the premise of the article, it wasn't NoSQL, so it must have been secure. In reality we were very secure from external breaches, at least as secure as you can reasonably be. Personal information was secured to the maximum extent possible. Encrypted, backed up to multiple independent tapes stored in separate locations etc. On the other hand, the overall complexity of the system was very high and if someone breached our network there would have been a very large surface area to attack. I didn't feel like the article addressed this aspect of security in the least. Security just isn't one of those things that are easy or are ever done. It takes constant vigilance and continuous adjustment and improvement.
- methodin 15y ago
  Did your institution go the seldom traveled route of encrypting sensitive information? Typically all the effort is spent trying to avoid breaches instead of protecting against them when they occur.
  - NyxWulf 15y ago
    Initially it was not encrypted and was stored in plain text in the database. Then we started encrypting sensitive information at rest, both the database files and the backups. We also encrypted certain sensitive information with a secondary encryption. The next massive undertaking was to find all of the processes that use the data, how they use it - both internally and externally, and then ensure the data was protected throughout the entire process. The company was still working through that process when I left. They had identified many places that were problematic and were actively working on fixing them. The team I managed was the payment processing and cash management team. There were a number of legacy systems written in access, fox pro, DTS, Excel even. Many of those were the most painful, and frankly the most problematic. Many people were put in a situation where the requirements for getting something implemented through the IT teams would take months, yet they were still held accountable for getting things done, so they would build an Excel process to get the job done. They would build some fantastic process, and get promoted, then that Excel system would get dumped on either someone in IT or someone replacing them. I'm getting off track, but looking at it superficially the data was encrypted. If, however, you watch the data through it's entire value stream, there are many places it is vulnerable. Given the state of affairs in most companies and how few of them think in terms of managing value streams, I expect my observations are fairly widely applicable.

datasage 15y ago

RDBMS's, put a large focus on data integrity and access within the datastore layer itself (To differing degrees); NoSQL systems more or less offload that responsibility into the application layer. There is still a responsibility of running it within a trusted network. This is a decision that may not be appropriate for everyone, but that does not make it wrong. Many people who used mySQL to power web applications did use just one credential to access the database. In that scenario the authentication overhead is pretty much just a waste of time.

luca_garulli 15y ago

Seems like NoSQL target was to solve small part of your Big-Data problem. This is changing because NoSQL can replace RDBMS in many fields and Security is becoming a MUST to have too. AFAIK OrientDB is the only NoSQL supports security: http://code.google.com/p/orient/wiki/Security http://code.google.com/p/orient/wiki/Security.