5 ms·

It's great to see a positive attitude toward security also gaining support in Government. I just wish all software projects felt the need to be more secure [0]

It's great to see a positive attitude toward security also gaining support in Government. I just wish all software projects felt the need to be more secure [0]: > Redis is designed to be accessed by trusted clients inside trusted environments. > While Redis does not try to implement Access Control, it provides a tiny layer of authentication that is optionally turned on editing the redis.conf file. > Redis does not support encryption. This is just broken by design software development. [1] It's irresponsible in 2016/2017 to assume you have impenetrable perimeter security. Redis' excuse is just bullshit. PostgreSQL supports authentication, SSL, and even client cert pinning. [0] https://redis.io/topics/security https://redis.io/topics/security [1] http://antirez.com/news/96 http://antirez.com/news/96 Edit: Loving the downvotes by butthurt developers who have never had a security audit...

theGimp 10y ago
Redis and Postgre are meant to play different roles. If you don't like what Redis does, you're welcome not to use it.
- kogepathic 10y ago
  > If you don't like what Redis does, you're welcome not to use it. I like what Redis does, and it's also heavily used in industry. What I am saying, not incorrectly, is that their approach to security is harmful to their users. Most of whom won't know, care, or implement additional security which they should. It's the same argument with HTTPS. Of course HTTPS is optional in a web server, but all major web servers support HTTPS, and there has been a concentrated push to have more people using SSL. e.g. LetsEncrypt We should be making it easier for people to deploy secure services. Redis' approach to security makes it extremely difficult for developers to deploy secure services. I'll say it again: It's irresponsible in 2016/2017 to assume you have impenetrable perimeter security.
  - jrudolph 10y ago
    I don't get why it would be that way? It's built to be deployed in a DMZ on a private network and that's how 99% of users (typically professionals) use it.
    - deleted 10y ago
      [deleted]
    - 1_2__3 10y ago
      The idea of a hardened perimeter around a soft squishy interior has been proven repeatedly not to work.
  - sgift 10y ago
    > I like what Redis does, and it's also heavily used in industry. What I am saying, not incorrectly, is that their approach to security is harmful to their users. Most of whom won't know, care, or implement additional security which they should. Then a different security story within redis wouldn't save them anyway. Security is not magic fairy dust that you sprinkle on something and then hope for the best.
    - eropple 10y ago
      This isn't really true. Envision a system where all components are secured by default: TLS-encrypted connections in and out (which doesn't currently really exist unless you put in the work), a VPN for entry, individualized SSH keys (via SSSD or something) for machine access controlled via group policies and whatever directory services are up for grabs. These are pretty commoditized parts that should be easily deployed and should be easily bolted together. And in such a universe, you do get a pretty strong security story without having to break your back. My main beef with stuff like Redis is that in almost every case I can think of it's selected by developers. Security isn't on their radar. The systemic component parts we currently have don't value security and offload it to the literally (not pejoratively) incompetent.
      - kogepathic 10y ago
        > My main beef with stuff like Redis is that in almost every case I can think of it's selected by developers. Security isn't on their radar. The systemic component parts we currently have don't value security and offload it to the literally (not pejoratively) incompetent. Yes, this is exactly the point I was trying to make.
  - zzzcpan 10y ago
    > Redis' approach to security makes it extremely difficult for developers to deploy secure services. TLS proxy is not extremely difficult to deploy if you really need to talk to redis that way. But you shouldn't be using redis if you do.
- z3t4 10y ago
  Authentication and encryption takes a lot of CPU, but turning security OFF for performance reasons should always be behind a configuration flag. It's illegal to break into something, but if you leave the door wide open the insurance company might not be so willing, and in some laws it's actually legal to walk into open rooms.
Jdam 10y ago
Different projects - different requirements. Perhaps you should assume people who are using it like this carefully weighted security against their requirements and came to the conclusion that it's a legit tradeoff. > This is just broken by design software development. This is just your "I know it all" mindset.
- eropple 10y ago
  > Perhaps you should assume people who are using it like this carefully weighted security against their requirements and came to the conclusion that it's a legit tradeoff. Perhaps. Or perhaps "well, I'll just use Redis because everyone else uses Redis." This is, in my experience, common. Most people choosing a stack aren't qualified to evaluate the security approach of their stack. I don't really have a problem with Redis when somebody's going to actually either do their homework on securing it or are knowingly taking on additional risk. But you have to know it to do it. And vanishingly few people do. (And they don't ask, because they don't know to ask. The five-minute-demo culture has seen to that.)
  - dahart 10y ago
    It's basically impossible to use Redis accidentally in the way you're suggesting - to have absolutely no idea what you're getting into and fail to understand that it can run out of memory and doesn't provide security. Sure maybe before you've ever tried it or read anything at all, but you can't get very far without finding out. You want Redis to support https so that people who haven't tried it and haven't read anything about it won't accidentally shoot themselves in the foot? Even if you're right, your argument convinces me it's smarter for Redis to not implement security and say so than to add some in an effort to hide things for people who don't know what they're doing. Do you have any evidence that the problem you're talking about actually exists wrt Redis? Do you have any evidence that vanishingly few people understand & do homework to offset the body of evidence of the growing number of people that can deal responsibly in security and that things are getting better over time?
    - eropple 10y ago
probablybroken 10y ago
Sometimes it can be safer to assume that something is completely insecure, than to assume ( incorrectly ) that it is. Not implementing any security on a product guarantees the former - outside of complete user incompetence. I would also say that guaranteeing security is beyond the scope of most projects, especially those with limited development resource ( Redis for example ).
rubyfan 10y ago
fork -> add feature -> pull request
zzzcpan 10y ago
There is no reason to use redis over a non-local network as it loses its performance appeal completely. Even talking to a redis server on a different rack doesn't make a lot of sense, unless you have a total control over a network there. So encryption by default goes against its value proposition.
dahart 10y ago
I took those statements to be suggesting that you should be aware and implement your own security. What do you need the https access for, and why is it irresponsible to separate the database concerns from the security concerns? I don't know, but it might be extra responsible of the Redis devs to suggest they shouldn't implement your security for you, and they should stick strictly to databases. I'm not currently using Redis, but I would like to, and I've looked at it several times recently. Initially, I had nearly the same reaction as you, but now I think I interpret it differently. I'd assume that you have to wrap any scalable or public Redis access in an API, you will never expose the DB directly, so https would only be used for dev work and for transport between the DB and the API layer. Both of those I would normally implement security around myself, and for API transport it is unlikely to matter when I have the API host and the DB host inside the same network. I would think that removing Redis from the security equation probably makes a security audit easier and not harder, since you would configure dev access over ssh & share existing keys, reducing the number of entry/failure points. Same for the API transport, if necessary.
- kogepathic 10y ago
  > I don't know, but it might be extra responsible of the Redis devs to suggest they shouldn't implement your security for you, and they should stick strictly to databases. Do you still agree if I change your statement to: I don't know, but it might be extra responsible of the nginx devs to suggest they shouldn't implement your security for you, and they should stick strictly to HTTP. I would imagine you would not agree, because it's ridiculous to have a web server only supporting HTTP in 2017. This is exactly my argument about Redis. I'm not saying Redis should implement their own crypto. I'm saying it's user hostile to say "We don't support security because perimeter security is infallible and plus no one really cares about security anyway" and you should go use another utility to wrap their socket in SSL. Sure, it's not their job to be security experts, but neither are the: - PostgreSQL developers - openLDAP developers - rsync developers And yet somehow they manage to support SSL within their application. If you read reports about data breaches lately, it's usually the following pattern: - Send a phishing email to someone in the org with malware - Infect their computer - Pivot inside the network and exfiltrate the goodies In this scenario, perimeter security is utterly worthless because the attacker has gotten themselves right into your network. If you have encrypted data between services (e.g. application servers to database, application to redis) then they also have to pop the actual servers to get the data, instead of just sitting on the network and watching traffic go back and forth. People say "oh it's not a big deal, redis is just storing sessions" until someone grabs a session from the app server to the redis server, and then pops your site as an admin.
Doctor_Fegg 10y ago
For info: downvoted you not because of butthurt, but because I believe "just bullshit", "it's irresponsible", and "butthurt" are unworthy of a civilised debate.
- kogepathic 10y ago
  > but because I believe "just bullshit", "it's irresponsible", and "butthurt" are unworthy of a civilised debate. The main beef I have is that on an article about expanding the use of transport layer security, people are arguing against implementing transport layer security. To me this is an incredibly hypocritical stance for people to take. You can downvote me because you disagree with the way I'm communicating my message, but I hope you don't disagree with the sentiment that we should be working to implement transport layer security everywhere and not just for protocols like HTTP. Also saying my points are unworthy of civilised debate because of the language I use strikes me as incredibly naive. Donald Trump says nasty things, but people can and do debate him because the issues at hand are important to them and to the public at large. Refusing to engage someone because you disagree with the language they're using, which in my case is not hate speech or discriminating against a specific group of people, is dangerous to civil society.

theGimp 10y ago

Redis and Postgre are meant to play different roles. If you don't like what Redis does, you're welcome not to use it.

kogepathic 10y ago
> If you don't like what Redis does, you're welcome not to use it. I like what Redis does, and it's also heavily used in industry. What I am saying, not incorrectly, is that their approach to security is harmful to their users. Most of whom won't know, care, or implement additional security which they should. It's the same argument with HTTPS. Of course HTTPS is optional in a web server, but all major web servers support HTTPS, and there has been a concentrated push to have more people using SSL. e.g. LetsEncrypt We should be making it easier for people to deploy secure services. Redis' approach to security makes it extremely difficult for developers to deploy secure services. I'll say it again: It's irresponsible in 2016/2017 to assume you have impenetrable perimeter security.
- jrudolph 10y ago
  I don't get why it would be that way? It's built to be deployed in a DMZ on a private network and that's how 99% of users (typically professionals) use it.
  - deleted 10y ago
    [deleted]
  - 1_2__3 10y ago
    The idea of a hardened perimeter around a soft squishy interior has been proven repeatedly not to work.
- sgift 10y ago
  > I like what Redis does, and it's also heavily used in industry. What I am saying, not incorrectly, is that their approach to security is harmful to their users. Most of whom won't know, care, or implement additional security which they should. Then a different security story within redis wouldn't save them anyway. Security is not magic fairy dust that you sprinkle on something and then hope for the best.
  - eropple 10y ago
    This isn't really true. Envision a system where all components are secured by default: TLS-encrypted connections in and out (which doesn't currently really exist unless you put in the work), a VPN for entry, individualized SSH keys (via SSSD or something) for machine access controlled via group policies and whatever directory services are up for grabs. These are pretty commoditized parts that should be easily deployed and should be easily bolted together. And in such a universe, you do get a pretty strong security story without having to break your back. My main beef with stuff like Redis is that in almost every case I can think of it's selected by developers. Security isn't on their radar. The systemic component parts we currently have don't value security and offload it to the literally (not pejoratively) incompetent.
    - kogepathic 10y ago
      > My main beef with stuff like Redis is that in almost every case I can think of it's selected by developers. Security isn't on their radar. The systemic component parts we currently have don't value security and offload it to the literally (not pejoratively) incompetent. Yes, this is exactly the point I was trying to make.
- zzzcpan 10y ago
  > Redis' approach to security makes it extremely difficult for developers to deploy secure services. TLS proxy is not extremely difficult to deploy if you really need to talk to redis that way. But you shouldn't be using redis if you do.
z3t4 10y ago
Authentication and encryption takes a lot of CPU, but turning security OFF for performance reasons should always be behind a configuration flag. It's illegal to break into something, but if you leave the door wide open the insurance company might not be so willing, and in some laws it's actually legal to walk into open rooms.

Jdam 10y ago

Different projects - different requirements. Perhaps you should assume people who are using it like this carefully weighted security against their requirements and came to the conclusion that it's a legit tradeoff. > This is just broken by design software development. This is just your "I know it all" mindset.

eropple 10y ago
> Perhaps you should assume people who are using it like this carefully weighted security against their requirements and came to the conclusion that it's a legit tradeoff. Perhaps. Or perhaps "well, I'll just use Redis because everyone else uses Redis." This is, in my experience, common. Most people choosing a stack aren't qualified to evaluate the security approach of their stack. I don't really have a problem with Redis when somebody's going to actually either do their homework on securing it or are knowingly taking on additional risk. But you have to know it to do it. And vanishingly few people do. (And they don't ask, because they don't know to ask. The five-minute-demo culture has seen to that.)
- dahart 10y ago
  It's basically impossible to use Redis accidentally in the way you're suggesting - to have absolutely no idea what you're getting into and fail to understand that it can run out of memory and doesn't provide security. Sure maybe before you've ever tried it or read anything at all, but you can't get very far without finding out. You want Redis to support https so that people who haven't tried it and haven't read anything about it won't accidentally shoot themselves in the foot? Even if you're right, your argument convinces me it's smarter for Redis to not implement security and say so than to add some in an effort to hide things for people who don't know what they're doing. Do you have any evidence that the problem you're talking about actually exists wrt Redis? Do you have any evidence that vanishingly few people understand & do homework to offset the body of evidence of the growing number of people that can deal responsibly in security and that things are getting better over time?
  - eropple 10y ago

probablybroken 10y ago

Sometimes it can be safer to assume that something is completely insecure, than to assume ( incorrectly ) that it is. Not implementing any security on a product guarantees the former - outside of complete user incompetence. I would also say that guaranteeing security is beyond the scope of most projects, especially those with limited development resource ( Redis for example ).

rubyfan 10y ago

fork -> add feature -> pull request

zzzcpan 10y ago

There is no reason to use redis over a non-local network as it loses its performance appeal completely. Even talking to a redis server on a different rack doesn't make a lot of sense, unless you have a total control over a network there. So encryption by default goes against its value proposition.

dahart 10y ago

I took those statements to be suggesting that you should be aware and implement your own security. What do you need the https access for, and why is it irresponsible to separate the database concerns from the security concerns? I don't know, but it might be extra responsible of the Redis devs to suggest they shouldn't implement your security for you, and they should stick strictly to databases. I'm not currently using Redis, but I would like to, and I've looked at it several times recently. Initially, I had nearly the same reaction as you, but now I think I interpret it differently. I'd assume that you have to wrap any scalable or public Redis access in an API, you will never expose the DB directly, so https would only be used for dev work and for transport between the DB and the API layer. Both of those I would normally implement security around myself, and for API transport it is unlikely to matter when I have the API host and the DB host inside the same network. I would think that removing Redis from the security equation probably makes a security audit easier and not harder, since you would configure dev access over ssh & share existing keys, reducing the number of entry/failure points. Same for the API transport, if necessary.

kogepathic 10y ago
> I don't know, but it might be extra responsible of the Redis devs to suggest they shouldn't implement your security for you, and they should stick strictly to databases. Do you still agree if I change your statement to: I don't know, but it might be extra responsible of the nginx devs to suggest they shouldn't implement your security for you, and they should stick strictly to HTTP. I would imagine you would not agree, because it's ridiculous to have a web server only supporting HTTP in 2017. This is exactly my argument about Redis. I'm not saying Redis should implement their own crypto. I'm saying it's user hostile to say "We don't support security because perimeter security is infallible and plus no one really cares about security anyway" and you should go use another utility to wrap their socket in SSL. Sure, it's not their job to be security experts, but neither are the: - PostgreSQL developers - openLDAP developers - rsync developers And yet somehow they manage to support SSL within their application. If you read reports about data breaches lately, it's usually the following pattern: - Send a phishing email to someone in the org with malware - Infect their computer - Pivot inside the network and exfiltrate the goodies In this scenario, perimeter security is utterly worthless because the attacker has gotten themselves right into your network. If you have encrypted data between services (e.g. application servers to database, application to redis) then they also have to pop the actual servers to get the data, instead of just sitting on the network and watching traffic go back and forth. People say "oh it's not a big deal, redis is just storing sessions" until someone grabs a session from the app server to the redis server, and then pops your site as an admin.

Doctor_Fegg 10y ago

For info: downvoted you not because of butthurt, but because I believe "just bullshit", "it's irresponsible", and "butthurt" are unworthy of a civilised debate.

kogepathic 10y ago
> but because I believe "just bullshit", "it's irresponsible", and "butthurt" are unworthy of a civilised debate. The main beef I have is that on an article about expanding the use of transport layer security, people are arguing against implementing transport layer security. To me this is an incredibly hypocritical stance for people to take. You can downvote me because you disagree with the way I'm communicating my message, but I hope you don't disagree with the sentiment that we should be working to implement transport layer security everywhere and not just for protocols like HTTP. Also saying my points are unworthy of civilised debate because of the language I use strikes me as incredibly naive. Donald Trump says nasty things, but people can and do debate him because the issues at hand are important to them and to the public at large. Refusing to engage someone because you disagree with the language they're using, which in my case is not hate speech or discriminating against a specific group of people, is dangerous to civil society.