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.
