A common question when hardening a Redis instance is: do I have to put my password in plain text in redis.conf? The short answer is yes – Redis has no built‑in facility for encrypting the requirepass directive – but there is a much better option starting with Redis 6.

Why the concern?

By default you can put a password into redis.conf like:

requirepass s3cr3t

Redis uses that string to authenticate clients. Anyone who can read your config file can see the secret. In environments where configuration files are shared or backed up, that becomes an obvious risk.

You might also try to avoid the config altogether by passing -a on the command line or setting REDISCLI_AUTH for redis-cli, but the server still needs the plain text to check incoming clients.

What Redis 6 gives you: ACLs with hashed passwords

Version 6 introduced the ACL subsystem, which lets you define multiple users and specify their permissions. One very handy side effect is the ability to specify a password as a SHA‑256 hash instead of plain text.

From redis-cli:

# create a user and give it the hashed password
acl setuser yourUser on #951249c8e32817cb0727ba2b1440f008c49c582e5daca4a0bd6d64eed1291a37

…and the equivalent snippet for redis.conf:

user yourUser on #951249c8e32817cb0727ba2b1440f008c49c582e5daca4a0bd6d64eed1291a37

The leading # tells Redis that the following value is already hashed. When a client authenticates with AUTH yourUser <password>, Redis hashes <password> with SHA‑256 and compares it against the stored value.

Important: the hash is not encryption. An attacker who reads redis.conf can’t recover your original password, but they can use the hash in an offline brute‑force attack to discover a matching password. Choose a strong passphrase accordingly.

Don’t forget to retaliate against the default user

Redis still creates a default user with no password and all commands enabled. That user can connect without authentication, so you should disable it when using ACLs:

acl setuser default off

or in redis.conf:

user default off

This ensures that only the accounts you explicitly define can access the instance.

Other hardening tips

  • Use protected-mode yes (it’s on by default) to prevent accidental exposure on public interfaces.
  • Run Redis under a reduced‑privilege account and use file‑system permissions to protect redis.conf and the RDB/AOF files.
  • Avoid storing secrets in VCS. Even if the password is hashed, it’s better to inject credentials at deployment time (via environment variables, vaults, etc.) and regenerate the config on the target machine.
  • Consider tls-port and tls-auth-clients for encrypted connections if you’re using Redis 6+ with TLS support.

When is encryption a thing?

Redis does not support encrypted configuration files or encrypted-at-rest keys. If you need that level of protection you’ll have to rely on the underlying filesystem (e.g. LUKS, BitLocker) or external secret‑management tools. The ACL hash feature only solves the problem of not keeping plain text passwords in redis.conf.

Summary

  • Redis itself never encrypts passwords – the server needs them in clear text to authenticate.
  • Starting with Redis 6 you can store SHA‑256 hashes of passwords in redis.conf using the ACL user syntax.
  • Hashing the password makes casual snooping harder, but it isn’t a substitute for proper secret management.
  • Disable the default user and apply other best practices (protected mode, file permissions, TLS) to secure your instance.

That’s all there is to it – no magical “encrypted password” flag, just a sensible use of ACLs to keep you from typing secrets into your config in the clear.