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 <[email protected]> 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 <[email protected]> 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 [email protected]. > > 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 [email protected]. > > 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 [email protected]. > 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
