Reject passwords that cannot be encrypted
At the moment, if services fails to encrypt a password, it will fall back to
storing it in plain text in the database. This is clearly undesirable. This
can happen for a couple of reasons off of the top of my head:
- No encryption-capable crypto providers are loaded.
This is extremely negligent, but is still possible. Services complains
loudly every time it attempts to encrypt a password in this configuration,
but that will not stop some negligent sysadmins from ignoring these
messages and continuing to run it in this configuration.
- pbkdf2v2 is the only encryption-capable crypto provider loaded, it is
configured in SCRAM mode with GNU libidn for SASLprep normalisation, and
the user supplies a password containing invalid UTF-8 byte sequences or
ASCII control characters.
- Either argon2 or scrypt are the only encryption-capable crypto provider
loaded, and they are configured to use far more memory than the system has
available; high enough to cause libc to fall back to a direct mmap(2), and
high enough for the kernel's overcommit logic to reject it as extreme,
returning NULL.
This is because set_password() has no way to indicate to its caller whether
it was able to encrypt the password or not.
This commit forces set_password() to encrypt the password or return failure
to its caller. The callers now check whether it was successful and abort
their operation if it was not.
Also add a note to the SASL SCRAM documentation mentioning the prohibited
password characters, and the same to the help files for commands that take
passwords (but only if the SASL SCRAM module is loaded).
Reject passwords that cannot be encrypted
At the moment, if services fails to encrypt a password, it will fall back to
storing it in plain text in the database. This is clearly undesirable. This
can happen for a couple of reasons off of the top of my head:
- No encryption-capable crypto providers are loaded.
This is extremely negligent, but is still possible. Services complains
loudly every time it attempts to encrypt a password in this configuration,
but that will not stop some negligent sysadmins from ignoring these
messages and continuing to run it in this configuration.
- pbkdf2v2 is the only encryption-capable crypto provider loaded, it is
configured in SCRAM mode with GNU libidn for SASLprep normalisation, and
the user supplies a password containing invalid UTF-8 byte sequences or
ASCII control characters.
- Either argon2 or scrypt are the only encryption-capable crypto provider
loaded, and they are configured to use far more memory than the system has
available; high enough to cause libc to fall back to a direct mmap(2), and
high enough for the kernel's overcommit logic to reject it as extreme,
returning NULL.
This is because set_password() has no way to indicate to its caller whether
it was able to encrypt the password or not.
This commit forces set_password() to encrypt the password or return failure
to its caller. The callers now check whether it was successful and abort
their operation if it was not.
Also add a note to the SASL SCRAM documentation mentioning the prohibited
password characters, and the same to the help files for commands that take
passwords (but only if the SASL SCRAM module is loaded).