11–20 of 35 posts
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.
I would tend to think financial/banking/ 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 usef…
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.
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…
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 ;) ).
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 dept…
I haven't tried it myself, but Redis has support for simple authentication at least. http://redis.io/topics/security
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.
I'm the author of a (very) new NoSQL datastore called 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 s…
I'm the author of a (very) new NoSQL datastore called 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 s…
I don't know what you're trying to say with regards to SSL, or how it can be reasonably compared to runtime hardening.
I'm the author of a (very) new NoSQL datastore called 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 s…
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.
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.
I'm the author of a (very) new NoSQL datastore called 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 s…
All firewalk did was port scan through firewalls. It wasn't some magic trick that got you root on them. I don't know what you're trying to say with regards to SSL, or how it can be reasonably compared to runtime hardening.
I didn't mean to imply TTL incrementation was magic remote root.
As far as SSL, you're right in that it is a bit tangential. I'm just trying to illustrate the huge security flaws that, in my eyes, stand in front of "can someone sniff my traffic".