Well, being extremely thorough; read from file on startup and then use online commands for modifications is perfectly doable too (and how some things work) but I feel like that will be hard for people to use.
On Tue, 17 Apr 2018, dormando wrote: > 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. > -- --- 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.
