> On Fri, May 4, 2018 at 10:46 PM dormando <[email protected]> wrote: > > The closest would be SCRAM-SHA-256/512 mechanism, but the RFC for that > states "in combination with TLS" up front, and I'd be wary of using it > over the internet as well. > > > If we ignore TLS for a second and just look at SCRAM it is fairly easy to > implement a minimalistic support for those mechanisms within SASL. There is > however one huge problem by using them in memcached without doing major > refactoring in the SASL support in memcached. By design SCRAM use a hashing > function with an iteration count, which should be set high enough to burn > enough CPU on both the client and the server to make brute force attacks > "impossible" (the RFC states that for SCRAM-SHA1 it should be _at least > 4096_). Given that the memcached runs the SASL operations in the _front end > threads_, it would block all the clients bound to that thread every time > someone tries to authenticate. If there is clients connecting all the time one > could end up with all worker threads running PBKDF2 hashing and all other > operations timing out ;) > > In order to add support for SCRAM you would have to move the hashing over to > a separate thread, and there is not an infrastructure for such thing in the > current memcached implementation so it would be a lot of work ;) >
There are actually mechanisms for passing connections to other threads in the code now :) It's used in a few places. It's not incredibly fast but connection rates typically aren't high enough to bother it. You'd still burn out your CPU though... but, it's moot. if you don't trust your network you can't just use SASL. :/ > Dormandos suggestion with stunnel (or ipsec) sounds like the least amount of > work, but if you _really_ don't want that (or you for some reason really > want to implement something yourself) you could look into changing memcached > to use libevents bufferevents instead of the "basic" form it use today, and > then add support for using the SSL level on top of bufferevents. I haven't > tested this so I have no idea of the overhead of this and how it would affect > the overall performance. Unless all your clients want to use SSL you probably > want a dedicated port and thread pool serving these connections. It all > depends on the performance requirements you've got... I'm more concerned about the poor person ending up stuck with a fork after weeks of work.. it's not exactly a straightforward change. I do intend to add TLS support this year. Would help if someone sponsored the work though :P -- --- You received this message because you are subscribed to the Google Groups "memcached" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
