3 ms·

Fair enough; I can understand why you'd want to (a) tune, and (b) make sure your benchmarks are going to stand up to scrutiny. Regarding 'secure by default', t

by donw 17y ago

Fair enough; I can understand why you'd want to (a) tune, and (b) make sure your benchmarks are going to stand up to scrutiny. Regarding 'secure by default', though, your answer is very hand-wavy. Do you employ cryptography for your network protocol? On-disk crypto for persisted data? Authentication? How are credentials stored, assuming you do provide authentication? What steps have you taken to avoid buffer overflow attacks? These are all questions that customers will ask; be prepared to answer them.

shin_lao 17y ago
Actually I was more referring to the hard work we do to avoid that kind of vulnerabilities by design: http://securitytracker.com/alerts/2010/Apr/1023839.html http://securitytracker.com/alerts/2010/Apr/1023839.html and http://securitytracker.com/alerts/2009/Apr/1022140.html http://securitytracker.com/alerts/2009/Apr/1022140.html Everything we do we consider security first and do threat modeling. All remote connections are done via TLS, we don't cipher the database on the disk but if there is a demand for it we'll add the feature. We've been extremely thorough to review the code an reduce the possibility for buffer overflows to occur. We use only safe API and validate input thoroughly. Buffers are encapsulated by a class in such a way that unsafe writing is difficult to do. I'm not claiming we'll never have an exploit, just saying we're doing the best we can to avoid it.
- moe 17y ago
  I would say those are non-issues in most deployments. Application caches are normally deployed within an isolated, trusted environment. TCP connections from untrusted clients simply don't happen, so hardening is not needed at that level. I'm confused about what use-case you have in mind with this. Is your cache meant to be exposed to the general public, sort of like the things you can do with couchdb?
  - shin_lao 17y ago
    We want indeed the software to be usable as a high-performance key/value storage system, which is why we think about security.

by donw 17y ago

shin_lao 17y ago

Actually I was more referring to the hard work we do to avoid that kind of vulnerabilities by design: http://securitytracker.com/alerts/2010/Apr/1023839.html http://securitytracker.com/alerts/2010/Apr/1023839.html and http://securitytracker.com/alerts/2009/Apr/1022140.html http://securitytracker.com/alerts/2009/Apr/1022140.html Everything we do we consider security first and do threat modeling. All remote connections are done via TLS, we don't cipher the database on the disk but if there is a demand for it we'll add the feature. We've been extremely thorough to review the code an reduce the possibility for buffer overflows to occur. We use only safe API and validate input thoroughly. Buffers are encapsulated by a class in such a way that unsafe writing is difficult to do. I'm not claiming we'll never have an exploit, just saying we're doing the best we can to avoid it.

moe 17y ago
I would say those are non-issues in most deployments. Application caches are normally deployed within an isolated, trusted environment. TCP connections from untrusted clients simply don't happen, so hardening is not needed at that level. I'm confused about what use-case you have in mind with this. Is your cache meant to be exposed to the general public, sort of like the things you can do with couchdb?
- shin_lao 17y ago
  We want indeed the software to be usable as a high-performance key/value storage system, which is why we think about security.