---
title: "Redis Password Generator: requirepass and ACL Users"
description: "Generate a long Redis password in your browser, nothing sent. Get ready requirepass, CONFIG SET and ACL SETUSER lines plus an encoded redis:// URL."
image: "https://cdn.sethserver.com/blog-images/redis-password-generator-social-1789657324.webp"
---

# Redis Password Generator: requirepass and ACL Users

generating...

Password length (16 to 256)

 URL-safe only (A-Z a-z 0-9 - . \_ ~)

ACL username

Key prefix the user may touch

### ACL user for your application (Redis 6+, recommended)

Run in redis-cli as an admin. The user can read and write keys under the prefix and nothing flagged dangerous.

### Add this as a second password (rotation)

Adds the new password without removing the old one. When every client uses the new one, remove the old password.

### requirepass line for redis.conf

### Set requirepass on a running server

Takes effect immediately. CONFIG REWRITE saves it to redis.conf so it survives a restart.

### Connection URLs (password percent-encoded)

First line: the ACL user. Second: the default user set by requirepass. Third: the ACL user over TLS.

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](https://www.sethserver.com/books/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](https://www.sethserver.com/ai/principle-of-least-privilege-in-the-ai-age.html) and my [opinionated security best practices](https://www.sethserver.com/security/seths-opinionated-security-best-practices.html).

## 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](https://www.sethserver.com/security/mongodb-password-generator.html), [SQL Server Password Generator](https://www.sethserver.com/security/sql-server-password-generator.html), [MySQL Password Generator](https://www.sethserver.com/mysql/mysql-strong-password-generator.html), [PostgreSQL Password Generator](https://www.sethserver.com/postgresql/postgresql-strong-password-generator.html), and the [API key generator](https://www.sethserver.com/security/api-key-generator.html).

-Sethers


```json
{"@context": "https://schema.org", "@graph": [{"@type": "WebApplication", "applicationCategory": "DeveloperApplication", "author": {"@type": "Person", "name": "Seth Black", "url": "https://www.linkedin.com/in/seth-black-tx"}, "description": "Generate a long random Redis password in your browser with ready requirepass, CONFIG SET and ACL SETUSER lines plus a correctly encoded redis:// or rediss:// URL.", "name": "Redis Password Generator", "offers": {"@type": "Offer", "price": "0", "priceCurrency": "USD"}, "operatingSystem": "Web", "url": "https://www.sethserver.com/security/redis-password-generator.html"}, {"@type": "FAQPage", "mainEntity": [{"@type": "Question", "acceptedAnswer": {"@type": "Answer", "text": "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."}, "name": "What is the difference between requirepass and Redis ACL users?"}, {"@type": "Question", "acceptedAnswer": {"@type": "Answer", "text": "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."}, "name": "How long should a Redis password be?"}, {"@type": "Question", "acceptedAnswer": {"@type": "Answer", "text": "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."}, "name": "Can a Redis user have two passwords at the same time?"}, {"@type": "Question", "acceptedAnswer": {"@type": "Answer", "text": "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."}, "name": "Do I need to URL-encode a Redis password?"}, {"@type": "Question", "acceptedAnswer": {"@type": "Answer", "text": "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."}, "name": "Should I use ACL GENPASS instead of this generator?"}, {"@type": "Question", "acceptedAnswer": {"@type": "Answer", "text": "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."}, "name": "Is this Redis password generator safe?"}]}]}
{"@context": "https://schema.org", "@type": "BreadcrumbList", "itemListElement": [{"@type": "ListItem", "position": 1, "name": "sethserver", "item": "https://www.sethserver.com/"}, {"@type": "ListItem", "position": 2, "name": "Tools", "item": "https://www.sethserver.com/tools/"}, {"@type": "ListItem", "position": 3, "name": "Redis Password Generator: requirepass and ACL Users", "item": "https://www.sethserver.com/security/redis-password-generator.html"}]}
```