Re: basic auth token support

[dormando]

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  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  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 

Re: basic auth token support

[dormando]

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  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  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 

Re: basic auth token support

[John Reilly]

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  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  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.

Re: basic auth token support

[dormando]

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  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.

Re: basic auth token support

[John Reilly]

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  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.

basic auth token support

[dormando]

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.