Right; I'm saying there needs to be a mechanism of loading what the current tokens are :) Which are probably going to be from a file on disk. A rotation would be staged modifications to this file + reload commands or auto reloading.
Pulling from file would be necessary to avoid losing tokens during transition periods if the process is restarted for any reason. This is unusual since memc doesn't have a habit of talking to the filesystem post-startup (extstore nonwithstanding), but should be okay. On Tue, 17 Apr 2018, John Reilly wrote: > Reload would be handy to have but not absolutely necessary. > For rotation, one would just set up their second token (the new one) at some > point in time. Any time after that clients can transition to the new token. > Once all clients are transitioned to the new token, the original token would > then need to be removed on the memcached server. > Thanks, > John > > On Mon, Apr 16, 2018 at 10:57 AM dormando <dorma...@rydia.net> wrote: > 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. > > -- > > --- > 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.
