3 ms·

At least last time I looked at it, ElasticSearch is shockingly insecure by default (as are Mongo, Cassandra, Hadoop, and everything else that's popular in the r

At least last time I looked at it, ElasticSearch is shockingly insecure by default (as are Mongo, Cassandra, Hadoop, and everything else that's popular in the relatively recent Java ecosystem).

snarf21 5y ago
Yeah, this is the same as Wi-Fi routers all being admin/password. They finally started assigning them random pwds. Why isn't secure by default chosen?
- l0b0 5y ago
  That's easy: perverse incentives. 1. Secure by default makes for a higher barrier to entry. It's human nature to want to keep barriers of entry low for your life's work. (I have similar thoughts around copyleft licenses being better for the users but hard to sell to the creators.) 2. Security is "available" to anyone savvy enough to clear all the hurdles to secure the system, so the creators feel justified to blame the user. 3. The product is developed with an assumption that something outside the product is supposed to provide security. For example, the Go.CD devs (excellent product otherwise) scoffed at the idea of improving their crappy password hashing (single round of SHA256 with no salt IIRC), instead suggesting that I should wrap the service in some other, safer authentication mechanism.
Saris 5y ago
It's crazy how much stuff is just no auth and listens on all interfaces by default.
MichaelMoser123 5y ago
For a system like ES there is encryption in transit and encryption at rest. https://docs.aws.amazon.com/elasticsearch-service/latest/developerguide/encryption-at-rest.html https://docs.aws.amazon.com/elasticsearch-service/latest/dev... amazon elastic search gives you the option of encrypting the data at rest (meaning it is encrypted by amazon ES when stored persistently) - they use KMS for key management, so it should have a per record symmetric key that is encrypted by master symmetric key. It's notable that the amazon fork has added this functionality, this does not seem to be part of elastic search proper (please correct me if I am wrong) Elastic search proper is only talking about encryption in transit https://www.elastic.co/what-is/elastic-stack-security?ultron=B-Stack-Trials-EMEA-Other-UK-Exact&gambit=Security-Elastic-Security&blade=adwords-s&hulk=cpc&Device=c&thor=elasticsearch%20encryption&gclid=CjwKCAjw3_KIBhA2EiwAaAAlii_hMSFyQZb8bikIOPqZV_vAakNhaFiM9D6JosZgt62eDBAyODFLvBoCXMYQAvD_BwE https://www.elastic.co/what-is/elastic-stack-security?ultron... Here they say that they don't have encryption at rest https://www.elastic.co/guide/en/cloud-enterprise/current/ece-securing-considerations.html https://www.elastic.co/guide/en/cloud-enterprise/current/ece... Now you can possibly encrypt the records at the application level, but that makes them unsearchable; however the ability to search the stuff is arguably the point of having it in elasticserarch.

At least last time I looked at it, ElasticSearch is shockingly insecure by default (as are Mongo, Cassandra, Hadoop, and everything else that's popular in the relatively recent Java ecosystem).

snarf21 5y ago

Yeah, this is the same as Wi-Fi routers all being admin/password. They finally started assigning them random pwds. Why isn't secure by default chosen?

l0b0 5y ago
That's easy: perverse incentives. 1. Secure by default makes for a higher barrier to entry. It's human nature to want to keep barriers of entry low for your life's work. (I have similar thoughts around copyleft licenses being better for the users but hard to sell to the creators.) 2. Security is "available" to anyone savvy enough to clear all the hurdles to secure the system, so the creators feel justified to blame the user. 3. The product is developed with an assumption that something outside the product is supposed to provide security. For example, the Go.CD devs (excellent product otherwise) scoffed at the idea of improving their crappy password hashing (single round of SHA256 with no salt IIRC), instead suggesting that I should wrap the service in some other, safer authentication mechanism.

Saris 5y ago

It's crazy how much stuff is just no auth and listens on all interfaces by default.

MichaelMoser123 5y ago

For a system like ES there is encryption in transit and encryption at rest. https://docs.aws.amazon.com/elasticsearch-service/latest/developerguide/encryption-at-rest.html https://docs.aws.amazon.com/elasticsearch-service/latest/dev... amazon elastic search gives you the option of encrypting the data at rest (meaning it is encrypted by amazon ES when stored persistently) - they use KMS for key management, so it should have a per record symmetric key that is encrypted by master symmetric key. It's notable that the amazon fork has added this functionality, this does not seem to be part of elastic search proper (please correct me if I am wrong) Elastic search proper is only talking about encryption in transit https://www.elastic.co/what-is/elastic-stack-security?ultron=B-Stack-Trials-EMEA-Other-UK-Exact&gambit=Security-Elastic-Security&blade=adwords-s&hulk=cpc&Device=c&thor=elasticsearch%20encryption&gclid=CjwKCAjw3_KIBhA2EiwAaAAlii_hMSFyQZb8bikIOPqZV_vAakNhaFiM9D6JosZgt62eDBAyODFLvBoCXMYQAvD_BwE https://www.elastic.co/what-is/elastic-stack-security?ultron... Here they say that they don't have encryption at rest https://www.elastic.co/guide/en/cloud-enterprise/current/ece-securing-considerations.html https://www.elastic.co/guide/en/cloud-enterprise/current/ece... Now you can possibly encrypt the records at the application level, but that makes them unsearchable; however the ability to search the stuff is arguably the point of having it in elasticserarch.