Memcached SASL authentication is surprisingly easy to bypass if you’re not careful about how you configure it.
Let’s see what it looks like when it’s actually working. Imagine a simple client trying to connect to a Memcached server that’s expecting SASL authentication.
import memcache
# Configure the client to use SASL authentication
# 'PLAIN' is a common mechanism, but others exist.
# You'd typically get these credentials from a secure store.
client = memcache.Client(['127.0.0.1:11211'],
server_max_key_size=250,
server_min_key_size=1,
debug=0,
username='myuser',
password='mypassword',
behaviors={'sasl': True})
# Attempt to set a value
try:
client.set("mykey", "myvalue")
print("Successfully set key.")
except Exception as e:
print(f"Failed to set key: {e}")
# Attempt to get a value
try:
value = client.get("mykey")
print(f"Retrieved value: {value}")
except Exception as e:
print(f"Failed to retrieve key: {e}")
This Python code uses the python-memcached library. When sasl: True is set in the behaviors, the client will automatically attempt to negotiate a SASL mechanism with the server. If the server is configured to require SASL and the provided username and password are valid for a supported mechanism (like PLAIN), the connection will proceed. Otherwise, the set and get operations will fail with an authentication error.
The core problem Memcached SASL authentication solves is preventing unauthorized access to your cached data. Without it, anyone who can reach your Memcached server over the network can read, write, or delete any data in the cache. This is a significant security risk, especially in multi-tenant environments or when caching sensitive information.
Internally, when a client connects to a Memcached server configured with SASL, the following happens:
- Connection Initiation: The client establishes a raw TCP connection to the Memcached server’s port (default 11211).
- SASL Negotiation: The client sends a
SASL.LIST_MECHScommand (or similar, depending on the library/protocol version) to discover the authentication mechanisms supported by the server. - Mechanism Selection: The client and server agree on a common mechanism. For basic username/password authentication, this is often
PLAIN. - Authentication: The client sends its credentials (username and password) to the server using the chosen mechanism. The
PLAINmechanism, for example, typically sends\0username\0passworddirectly. The server validates these credentials against its configured SASL mechanism (e.g.,saslauthdwith PAM, LDAP, or a static file). - Authorized Operations: If authentication succeeds, the server allows subsequent Memcached commands (GET, SET, DELETE, etc.) from that client connection. If it fails, the server will respond with an authentication error, and the client will likely close the connection or retry with different credentials.
The exact levers you control are primarily on the server side. You configure which SASL mechanisms Memcached should advertise and expect. This is done via command-line arguments or configuration files when starting the memcached process.
For example, to enable SASL authentication using saslauthd (a common PAM-based authentication daemon), you might start memcached like this:
memcached -p 11211 -I 1m -S -X -m 64 -c 2048 --enable-sasl --sasl-mechanisms "PLAIN" --sasl-authd-path "/var/run/saslauthd/mux"
Let’s break down the relevant flags:
--enable-sasl: This is the master switch to turn on SASL support. Without it, Memcached ignores any SASL-related configurations and allows unauthenticated access.--sasl-mechanisms "PLAIN": This tells Memcached which authentication mechanisms it should advertise to clients.PLAINis the simplest, transmitting credentials in plaintext (though the connection itself should be secured via TLS/SSL if you’re concerned about network eavesdropping of the credentials themselves). Other mechanisms likeCRAM-MD5orDIGEST-MD5offer more robust protection against eavesdropping but are more complex to set up.--sasl-authd-path "/var/run/saslauthd/mux": This points Memcached to the communication socket forsaslauthd.saslauthdis a daemon that handles authentication requests by interfacing with the system’s Pluggable Authentication Modules (PAM). This means your Memcached users and passwords would be managed by your operating system’s user accounts.
The one thing most people don’t know is that Memcached itself doesn’t store or manage users and passwords for SASL. It delegates this responsibility entirely to an external SASL mechanism provider, most commonly saslauthd. If saslauthd isn’t running, or if the PAM configuration it uses doesn’t allow the specified user, authentication will fail even if Memcached is configured correctly. You need to ensure saslauthd is running, configured to use appropriate PAM services (like login or system-auth), and that the user you’re trying to authenticate with exists in the system’s user database.
The next step after securing your Memcached instances with SASL is to consider network-level security for your cache.