- Date: 2024-07-16
- Author: Rémi Bardon <[email protected]>
- Status: Accepted via #44 (2024-07-19)
- Relates to:
- Store workspace data in a vCard (2024-07-14)
- Superseded by: ø
- Deprecated: No
At the time of writing this ADR, the Prose Pod API needs two XMPP accounts to work properly. Those "service" accounts are made to be accessed only by the Prose Pod API and no other party should ever log into it.
The first account is the "super admin" account, [email protected], which is used to make administration changes to the Prose Pod Server (e.g. reloading the server configuration or creating users). Because it needs to exist before the Prose Pod API can even send a request to the Prose Pod Servern, this account is created automatically by the XMPP server when it starts, and the password must be known by both parties. We use environment variables to share this secret information, but a malicious Prosody plugin or just a bad code logging environment variables could expose critical credentials.
The second account is the workspace account, prose-workspace@<host>, as detailed in ADR: Store workspace data in a vCard. This account is created by the Prose Pod API and has a random password. The Prose Pod API doesn't store the password anywhere, for obvious security reasons, therefore it cannot recover it after a restart. Since the "super admin" account can create XMPP users and change their passwords, a solution is to override the workspace account password with a new random one the Prose Pod API will once again store in memory.
This ADR is there to document this decision but also generalize the process to the "super admin" account and every "service" account we will create in the future.
To ensure no one can log into XMPP accounts made to be used only by the Prose Pod API (to prevent privilege escalation), we will rotate the passwords of "service" accounts every time the Prose Pod API starts. The "super admin" account password will become a "bootstrapping password", used for a few seconds to allow the Prose Pod API to send a first request to the Prose Pod Server. asking it to change its own password.
By locking passwords access during this procedure, we could rotate all passwords more often if we feel the need. It's a very fast operation so we could transparently do it very often with virtually no impact for API users.
Since passwords are random, not predefined nor stored, we won't be able to run two instances of the same Prose Pod API at the same time to scale horizontally. It's not something we plan on doing therefore this is not an issue.
Other than that, the password rotation is completely transparent so apart from preventing unwanted access I don't see more consequences.