Maintain an OpenSSL SRP Verifier File Safely

openssl srp edits a file of usernames, salts and password verifiers, and its own help text calls it deprecated. This guide covers adding, listing, changing and removing users without wrecking the file or leaking a credential. Examples use OpenSSL 3.6.1 on this machine; the Debian package here reports 3.0.13, so check the binary you actually run before copying anything into a deployment.

Allow about fifteen minutes. You need the OpenSSL command and a path where you can create a private file. Because the tool manages an old SRP password-file format rather than a general user database, do not wire it into a new service without first checking that service still speaks this format.

1. Check the binary and its warning

Start with read-only checks. No elevated privileges are needed when the verifier file belongs to your user:

$ command -v openssl
/home/linuxbrew/.linuxbrew/bin/openssl
$ openssl version
OpenSSL 3.6.1 27 Jan 2026
$ openssl srp -help
Usage: srp [options] [user...]

The manual calls srp deprecated. That is a compatibility warning, not a reason to touch an existing verifier file today. Treat it as a reason to keep the workflow isolated, record the OpenSSL version you used, and plan a migration if the consuming service ever offers a supported mechanism instead.

2. Prepare a private verifier file

-srpvfile makes the command operate directly on the named file, and on this installation the file must already exist before the first operation. For a new path, create it without truncating anything that might already be there, then lock it down:

$ umask 077
$ touch "$HOME/srp-verifiers.txt"
$ chmod 600 "$HOME/srp-verifiers.txt"
$ ls -l "$HOME/srp-verifiers.txt"
-rw------- 1 your-user your-group 0 ... /home/your-user/srp-verifiers.txt

• Treat it as authentication material. It holds salts and verifiers, not clear-text passwords, but it can still be used to attack accounts. Keep it out of source control and any backup that is not protected to the same standard.
• Use sudo sparingly. Reach for it only when the service's account, or an existing protected directory, requires it.
• Mind the permissions if root creates the file. The service account must be able to read it, and ordinary users must not be able to replace it.

Do not overwrite an existing file with the install command. If the path already exists, stop and inspect it first:

$ stat "$HOME/srp-verifiers.txt"
$ openssl srp -srpvfile "$HOME/srp-verifiers.txt" -list

An empty file produces:

List all users

3. Add one user

Choose one action flag, the verifier file, an SRP group, and the username. -gn selects the RFC 5054 group strength for a new verifier; the installed command accepts 1024 as a group identifier:

$ openssl srp -srpvfile "$HOME/srp-verifiers.txt" \
    -add -gn 1024 -userinfo 'staging account' alice
Enter pass phrase for alice:
Verifying - Enter pass phrase for alice:

Enter the SRP password at both prompts. It is deliberately never placed on the command line or in shell history. A successful add exits quietly, so check it straight away:

$ printf 'exit status: %s\n' "$?"
exit status: 0
$ openssl srp -srpvfile "$HOME/srp-verifiers.txt" -list
List all users
alice

The username is a positional argument, not the value of an option, so quote it if your local account naming allows characters the shell would otherwise interpret. Do not chain unrelated operations in one invocation: -add, -modify, -delete and -list are mutually exclusive.

4. List a whole file or one user

Use -list without a username for every entry, or append one or more usernames to narrow the check:

$ openssl srp -srpvfile "$HOME/srp-verifiers.txt" -list alice
List all users
alice
$ openssl srp -srpvfile "$HOME/srp-verifiers.txt" -list bob
List all users
user "bob" does not exist, ignored.

The exact diagnostic wording is version-specific, so trust the exit status as well as the text. A missing user is not evidence that the file itself is missing, corrupt or unreadable. If the command reports that it cannot load or parse the file, stop before changing anything and check the path, ownership, permissions and whether another tool has quietly written a different file format there.

5. Change a verifier

Use -modify for an existing username. This is security-sensitive because it changes the credential the service will accept. Arrange a maintenance window if the account is active, and warn the user their old SRP password is about to stop working:

$ openssl srp -srpvfile "$HOME/srp-verifiers.txt" \
    -modify -gn 1024 -userinfo 'rotated staging account' alice
Enter pass phrase for alice:
Verifying - Enter pass phrase for alice:

Verify the entry is still there:

$ openssl srp -srpvfile "$HOME/srp-verifiers.txt" -list alice
List all users
alice

$ cp --preserve=mode,ownership,timestamps \
    "$HOME/srp-verifiers.txt" "$HOME/srp-verifiers.txt.before-alice-change"

If the change turns out wrong, stop the dependent service if you need to, then restore that copy only after checking its owner and mode. Never restore a stale copy over newer account changes.

6. Delete a user deliberately

$ cp --preserve=mode,ownership,timestamps \
    "$HOME/srp-verifiers.txt" "$HOME/srp-verifiers.txt.before-delete"
$ openssl srp -srpvfile "$HOME/srp-verifiers.txt" -delete alice
user "alice" deleted.

Check the user is actually gone:

$ openssl srp -srpvfile "$HOME/srp-verifiers.txt" -list alice
List all users
user "alice" does not exist, ignored.

$ install -m 600 "$HOME/srp-verifiers.txt.before-delete" \
    "$HOME/srp-verifiers.txt"
$ openssl srp -srpvfile "$HOME/srp-verifiers.txt" -list alice

If the file belongs to a service account, preserve that ownership on restore too. A successful restore the service cannot read is still an outage.

7. Use a configuration section only when needed

The alternative is -config CONFIG_FILE -name SECTION. Reach for it when the existing OpenSSL setup already defines an SRP section and you need the command to pick that definition; otherwise -srpvfile is easier to audit because the target file is right there in the command. Do not invent a section name or assume the system-wide OpenSSL configuration has one: inspect the configuration the service actually supplies, and test against a copy first.

-passin and -passout feed the input and output file password source using OpenSSL's passphrase-source syntax. They are separate from the interactive SRP password prompts shown above, and secrets belong in a safer passphrase source, not directly in process arguments.