I was reading the adminâs manual in nextcloudâs documentation and read:
The user password is also stored encrypted in the Nextcloud database. For encryption of the password, the token and an instance-specific secret is used.
[âŠ]
An actor with access to the access token, the Nextcloud config file, and the Nextcloud database can decrypt user passwords stored in the database.
I was wondering why is this the case and the passwords are not just hashed using Argon2id + Salt or some other similar standard secure setup.
I donât know if thereâs a reason for this but it just seems like an unnecessary security problem.
I was wondering why is this the case and the passwords are not just hashed using Argon2id + Salt or some other similar standard secure setup.
The current documentation is ambiguous and outdated in this area. Iâll see what I can do about that, but to respond briefly to your specific question:
Disclaimer: This has not been peer-reviewed, but I believe it is broadly accurate based on my reading of the underlying code.
The encrypted password mentioned in the manual is a separate, recoverable copy stored in association with a server-side authentication-token record. When auth.storeCryptedPassword is enabled â which it is by default â and the login password is available to Nextcloud, this copy may be stored for features that need the original credential, such as external storage access. A one-way Argon2id hash cannot support those uses because the original password cannot be recovered from it.
I donât know if thereâs a reason for this but it just seems like an unnecessary security problem.
It does represent a security-versus-functionality tradeoff. Administrators can disable the behavior if they do not require the associated functionality. The current documentation is unclear because it does not distinguish the one-way account-password hash from the reversibly encrypted copy associated with an authentication-token record.
Your post nudged me to start drafting a revision of that section that makes this distinction explicit and attempts to clarify/update some other related details. Iâll submit a PR to the documentation repository shortly to get further review and feedback.
Passwords generally shouldnât be encrypted at all. Hashing with a slow, password-specific algorithm like Argon2id is the safer approach, since the original password canât be recovered if the database is compromised.