Hey, Thanks for the feedback! That should be doable. I'm used to this being a pain with TLS ticket rotation/etc anyway. This'll probably end up requiring a reload mechanism but shouldn't be too messy, I guess?
On Mon, 16 Apr 2018, John Reilly wrote: > Hi dormando,I would love to see this change. One thing that would be great > to have is support for multiple tokens for the purpose of key rotation. If > there are roles, one could just assign 2 equivalent roles with different > tokens, but in the absence of roles as you mentioned just having the ability > to > define multiple tokens on the server level would work nicely. This is an > issue today with the redis password mechanism - once it is set, changing the > token across all clients and server at the same time is problematic. > > Of course, sasl already supports this so clients that want this capability > can use sasl, but it would be nice to have it available in any new default > authentication mechanism. > > Thanks, > John > > On Wed, Apr 11, 2018 at 1:59 AM dormando <dorma...@rydia.net> wrote: > Hey, > > In the wake of all this exposed-internet fun, I want to do something I > should've years ago; add support for a basic authentication token. > > Currently, with binary protocol, you have the option of using SASL. This > requires compiling against sasl, a client that both speaks binprot and > sasl, and understand the sasl ecosystem enough to generate > configurations, > password files, hook it up to kerberos, or what have you. This is > useful; > I should also see if ascii can support it. > > However, it's not simple. It can never be a default. > > I propose to do more or less what redis does, except I'd call it a token > instead of a password. Both ascii and binprot would support it. > > There are two options I'm considering: > > 1) add a new command, "auth [token]", or "auth [length]\r\ntoken" > > or: > > 2) if a connection is in an unauthenticated state, it will only accept a > "set auth [etc]\r\ntoken" magic key. > > It should be possible to extend this down the line if we want roles for > tokens by just having multiple tokens on the server.. > > It would be passed by commandline (it would rewrite the string on start) > and/or passed as a file to open and read on start. A restart would be > required to change the token. > > Plaintext only on both ends, no hashing. It should exist to help prevent > accidents more than anything else. I will probably add a delay on > failure > to mitigate brute-force, but no other features. > > The really hard part is adding support to clients, and perhaps in a few > years distro's can start shipping with default or randomized auth > tokens. > > Open to feedback. Thanks! > -Dormando > > -- > > --- > 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 memcached+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > > -- > > --- > 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 memcached+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > > -- --- 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 memcached+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
