Require authentication with Redis ACL users

The fix/etc/redis/redis.conf

user default off
user app on >REPLACE_WITH_LONG_RANDOM_SECRET ~app:* &* +@all -@dangerous

Generate a real secret rather than inventing one:

openssl rand -base64 48

Then restart, and update your application’s connection string to authenticate as app.

Why it matters

Redis executes whatever it is told. Without authentication, anyone who reaches the port can read every key, delete the dataset with a single FLUSHALL, and — via CONFIG SET — write files as the Redis user, which is a well-trodden path to code execution.

Authentication is the layer that survives a network mistake. It is not the primary control — binding is — but it is what stands between a misconfigured firewall rule and a total compromise.

Use ACL users, not requirepass

Since Redis 6, ACLs are the recommended authentication method, and requirepass is a compatibility layer that simply sets the password for the default user. It is not a separate, simpler system — it is one shared account with unlimited permissions.

That distinction is the whole argument:

	requirepass	ACL users
Identity	One shared secret	Named users
Permissions	Everything	Scoped per user
Rotation	Restart every client at once	Per user
Audit	Cannot tell callers apart	ACL WHOAMI, per-user

Turning off default and creating a named user for each caller costs one line each and gives you the thing shared secrets can never give you: the ability to revoke one client without breaking the rest.

Reading the rule syntax

user app on >secret ~app:* &* +@all -@dangerous

Token	Meaning
on	Account enabled
>secret	Add this password
~app:*	May only touch keys matching app:*
&*	May use any pub/sub channel
+@all -@dangerous	Allow everything except the dangerous category

Key patterns are the underused half. A cache user scoped to ~cache:* cannot read your session keys even if the credential leaks — that’s a blast-radius reduction no password length gives you.

For an aclfile instead of inline config, see restricting commands, which covers the category rules in detail.

Verify it worked

List the users the running server actually has:

redis-cli -u redis://app:SECRET@127.0.0.1:6379 ACL LIST

Confirm default is off:

user default off ...
user app on #<hash> ~app:* &* +@all -@dangerous

Then prove unauthenticated access fails:

redis-cli PING

Expect NOAUTH Authentication required. If it returns PONG, the default user is still enabled and the instance is effectively open.

Check who you are authenticated as:

redis-cli -u redis://app:SECRET@127.0.0.1:6379 ACL WHOAMI

Before you apply this

Turning off default breaks every client that isn’t sending a username. This is the change most likely to take an application down, because the old AUTH <password> form authenticates as default — so a client using requirepass today will fail the moment you disable that user.

Order of operations that avoids the outage:

1. Create the app user while default is still on.
2. Update and deploy the application’s connection string to use it.
3. Confirm traffic is arriving as app: redis-cli ACL GETUSER app.
4. Only then set user default off.

Also: the password is in a world-readable config file unless you fix that. See file permissions — writing a secret into redis.conf and leaving it 644 moves the problem rather than solving it.

Related

• Bind Redis to a private interface — do this first.
• Restrict dangerous commands with ACLs — the category rules in full.
• Secure the config and data files — where the secret lives.