Why NoSQL Equals NoSecurity

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.

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.

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?

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.