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"


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!


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.

Reply via email to