Redis Password Generator: requirepass and ACL Users

The password is generated in your browser with crypto.getRandomValues. It isn't sent to my server and it isn't stored anywhere. The ACL, config and URL lines update as you change the options.

Redis is the database people forget is a database. It starts life as "just the cache," ends up holding sessions, job queues and rate limit counters, and more often than I'd like it's listening on a public interface with no password at all. If you're here, you're already doing better than that.

requirepass vs ACL users

Redis has two ways to require a password, and since Redis 6 they're really the same mechanism wearing two hats.

requirepass is the original: one shared password for every client, set in redis.conf and sent with AUTH password. Since Redis 6, the ACL docs say it now sets the password for the built-in default user. You can see that for yourself: after CONFIG SET requirepass, ACL LIST shows user default on #<sha256> ... instead of nopass.

ACL users are named accounts created with ACL SETUSER. Each has its own passwords, its own allowed commands and its own key patterns, and clients log in with AUTH username password. That's what you want for applications. Your web app doesn't need CONFIG, FLUSHALL or KEYS, and your background worker doesn't need access to session keys.

The generated ACL command looks like this:

ACL SETUSER app on ">PASSWORD" resetkeys ~app:* resetchannels -@all +@read +@write +@connection +@transaction -@dangerous

Rules apply left to right. on enables the user, >PASSWORD adds a password, ~app:* limits keys, resetchannels denies all Pub/Sub channels, and the category rules start from nothing and add reads, writes, connection commands (PING, SELECT and friends) and MULTI/EXEC, then strip anything in the @dangerous category. If the app uses Pub/Sub, add +@pubsub &app:*. I quote the password argument so redis-cli treats it as one token no matter which symbols it contains.

That last -@dangerous matters more than it looks. The ACL docs point out that key patterns only restrict commands that name keys, so a user limited to ~tenant1:* can still run FLUSHALL and wipe everything if its command rules allow it. FLUSHALL, FLUSHDB and KEYS are all in @dangerous. I checked the generated rule on Redis 8: the user can SET app:x, gets NOPERM on SET other:x, and gets NOPERM on FLUSHALL.

If your client library runs something at connect time that the ACL blocks, you'll see a NOPERM error naming the command. Add just that command (for example +info) rather than going back to +@all. Then make sure the default user can't be used as a back door: give it a password with requirepass, or turn it off with ACL SETUSER default off once your admin user exists.

Where the password goes

Place	What to use
redis.conf	requirepass "PASSWORD", or user app on ">PASSWORD" ... lines, or aclfile /etc/redis/users.acl
Running server	CONFIG SET requirepass or ACL SETUSER, then CONFIG REWRITE (for config-file users) or ACL SAVE (for an aclfile)
Application	An environment variable or secrets manager holding the URL or the password
redis-cli	redis-cli --user app --askpass

A config change made with CONFIG SET or ACL SETUSER lives only in memory. Restart Redis and it's gone, which is a fun way to find out your app was relying on it. CONFIG REWRITE writes the running config back to redis.conf. If you use an external aclfile, the docs note that CONFIG REWRITE does not save ACL users; you need ACL SAVE. The two methods are mutually exclusive, so pick one.

One Docker gotcha I hit while testing this page: on the official redis:8 image, CONFIG REWRITE also copied the image's loadmodule lines into my redis.conf, and the next start aborted because a module was loaded twice. The new password had been saved correctly; deleting the loadmodule lines fixed the restart. If you run that image, edit redis.conf yourself instead of rewriting it.

Redis stores ACL passwords as SHA-256 hashes, which is why ACL LIST and a saved ACL file show # followed by 64 hex characters rather than your password. You can also put that hash in the file yourself with the #<hash> rule so the plaintext never touches disk.

Skip redis-cli -a PASSWORD. redis-cli itself warns that passing a password with -a or -u on the command line may not be safe, since it lands in your shell history and the process list. --askpass prompts instead.

Why Redis passwords need to be long

The Redis security docs give two reasons, and both are good. First, Redis is very fast at serving queries, so an external client that can reach the port can test many passwords per second. Second, the password lives in redis.conf and client configuration, never in a human brain, so there's no reason not to make it very long.

There's a third reason in the ACL docs. Redis deliberately hashes passwords with plain SHA-256 so AUTH stays fast, and it says slowing that down with a password-hardening algorithm would be a poor choice. Its advice instead is to use passwords strong enough that a dictionary or brute force attack fails even if someone gets the hash. That puts the whole burden on length and randomness, which is exactly what this page is for. The default of 40 characters from the full set is about 259 bits; the URL-safe set gives about 242 bits at the same length.

ACL GENPASS: the server-side alternative

Redis can generate a password for you:

127.0.0.1:6379> ACL GENPASS
"caf44bf2b61488e6c65004645217b0ce10d8722879f2d0cb0a625b1d73acc9b0"
127.0.0.1:6379> ACL GENPASS 128
"81aa8e5d1caf079309bbd5c7bd59be3a"

By default it returns 256 bits as 64 hex characters, and you can ask for anywhere from 1 to 1024 bits (rounded up to a multiple of 4). It's seeded from /dev/urandom. Hex has the nice property of never needing escaping in a config file, a shell or a URL. The only thing it doesn't do is build the ACL line and URL for you, which is the part this page adds.

Other ways to get one offline:

openssl rand -hex 32
python3 -c "import secrets; print(secrets.token_urlsafe(32))"
node -e "console.log(require('crypto').randomBytes(32).toString('base64url'))"

Rotating a Redis password without downtime

This is where ACL users earn their keep. The ACL docs say every user can have any number of passwords, so rotation is a three-step affair with no window where clients fail:

# 1. add the new password alongside the old one
ACL SETUSER app ">NEW-PASSWORD"

# 2. deploy the new password to every client, restart them, watch for auth errors

# 3. remove the old password
ACL SETUSER app "<OLD-PASSWORD"

Because ACL SETUSER applies rules incrementally, step 1 doesn't touch the user's other permissions. I tested this on Redis 8: during the overlap both passwords authenticate, and after step 3 only the new one does. Remember to ACL SAVE or CONFIG REWRITE afterward.

requirepass can't do this. CONFIG SET requirepass swaps the default user's password in one step, and every client still holding the old one fails its next AUTH. If you're still on requirepass, the migration path is: create an ACL user with the same access, move your apps to it, then lock down the default user.

Protected mode, bind and the Docker surprise

A password is the second line of defense. The first is not letting strangers reach port 6379. The Redis docs are clear that Redis is designed for trusted clients in trusted environments and that the port should be firewalled from everyone else. bind 127.0.0.1 in redis.conf keeps it on loopback.

Since 3.2, Redis has protected mode: when it's running with the default configuration (all interfaces) and no password, it only answers loopback clients and tells everyone else how to fix their setup. Setting a password takes you out of that situation, which is one more reason the password needs to be strong.

Here's the surprise. The official redis Docker image, started without a config file, runs with protected mode off and binds every interface. I checked with redis:8: CONFIG GET protected-mode returns no and CONFIG GET bind returns * -::*. That's reasonable inside a private Docker network and terrible with -p 6379:6379 on a public host. Mount a redis.conf with a password, or at least don't publish the port.

TLS: rediss://

AUTH is sent in cleartext like every other command unless the connection uses TLS, so a password doesn't protect you from someone who can watch the network. Redis supports TLS for client connections, replication and the cluster bus when it's built with TLS support. The relevant redis.conf settings are tls-port, tls-cert-file, tls-key-file and tls-ca-cert-file, and port 0 turns off the plaintext port. Clients connect with a rediss:// URL (two s's). Most managed Redis services give you a rediss:// URL already.

Encoding a Redis password in a URL

A Redis URL looks like redis://username:password@host:6379/0. Characters like @ : / ? # in the password break the parse, and % starts an escape, so the generator percent-encodes everything except letters, digits and - . _ ~. redis-py decodes it back (with redis-py 8.1, redis://default:a#b@localhost is a parse error while a%23b becomes a#b), and so does redis-cli -u. I verified both against a live Redis 8 server with a password containing every symbol the generator uses.

Use the raw password everywhere else: redis.conf, CONFIG SET, ACL SETUSER, AUTH. If you want to skip encoding entirely, tick "URL-safe only" and the encoded form is identical to the password.

Common mistakes

• Password set, port still public. The password is a backstop, not a firewall.
• CONFIG SET without CONFIG REWRITE. Works until the next restart.
• Apps using the default user. One password with +@all on every key. Give each app an ACL user.
• Forgetting replicas. A replica of a password-protected primary needs masterauth (and masteruser if it authenticates as an ACL user).
• Short passwords because "it's just a cache." The cache usually has sessions in it.
• Unencoded URL. A # in the password turns the rest of the URL into a fragment.

Redis is often the first "extra" piece that shows up next to the main database, and my book Databases in the Era of AI covers when that's the right call. For the permissions side, I've written about least privilege in the AI age and my opinionated security best practices.

Redis password FAQ

What is the difference between requirepass and Redis ACL users?

requirepass is the original single shared password. Since Redis 6 it simply sets the password of the built-in default user, and clients authenticate with AUTH password. ACL users are named accounts created with ACL SETUSER, each with its own passwords, allowed commands and key patterns, and clients authenticate with AUTH username password. Use ACL users for applications and keep the default user locked down or turned off.

How long should a Redis password be?

Long. The Redis security docs point out that Redis answers queries very quickly, so an attacker who can reach the port can try many passwords per second, and that nobody has to remember the password, so it can be very long. ACL GENPASS produces 256 bits by default. This generator defaults to 40 characters, which is about 259 bits from the full character set.

Can a Redis user have two passwords at the same time?

Yes, if it is an ACL user. The ACL docs say every user can have any number of passwords. Add the new one with ACL SETUSER app >newpassword, roll it out to your clients, then remove the old one with ACL SETUSER app <oldpassword. requirepass does not give you that overlap, because CONFIG SET requirepass replaces the default user password in one step.

Do I need to URL-encode a Redis password?

Only inside a redis:// or rediss:// URL. Characters such as @ : / ? # and % change how the URL is parsed, so they have to be percent-encoded, and client libraries such as redis-py decode them back. In redis.conf, CONFIG SET, ACL SETUSER and AUTH, use the raw password.

Should I use ACL GENPASS instead of this generator?

ACL GENPASS is a fine choice. It returns 64 hex characters, 256 bits, from a generator seeded by /dev/urandom, and it never leaves the server. Hex never needs escaping anywhere. Use this page when you want the ready ACL, config and URL lines built for you, or when you want symbols in the password.

Is this Redis password generator safe?

The password is generated in your browser with crypto.getRandomValues. Nothing is sent to my server or stored. If your rules say production secrets must be generated on your own infrastructure, run ACL GENPASS or openssl rand -hex 32 instead; both are shown on this page.

Related tools: MongoDB Password Generator, SQL Server Password Generator, MySQL Password Generator, PostgreSQL Password Generator, and the API key generator.

-Sethers