docs: update database setup instructions and clarify persistent data directory usage

Author: JasonKrik

services/backend/DB.md

@@ -26,21 +26,25 @@ To perform the initial setup of the database, use the following endpoint:
 
 **For SQLite:**
 The server will automatically manage the database file location. The request body should be:
+
 ```json
 {
   "type": "sqlite"
 }
 ```
+
 The SQLite database file will be created and stored at: `services/backend/persistent_data/database/deploystack.db`.
 
 **For PostgreSQL:**
 The request body should be:
+
 ```json
 {
   "type": "postgres",
   "connectionString": "postgresql://username:password@host:port/mydatabase"
 }
 ```
+
 Replace the `connectionString` with your actual PostgreSQL connection URI.
 
 **Important:** After the initial database setup via this API, you **must restart the backend server** for the changes to take full effect and for the application to connect to the newly configured database.
@@ -168,6 +172,7 @@ You can inspect the SQLite database directly using various tools:
   ```bash
   sqlite3 services/backend/persistent_data/database/deploystack.db
   ```
+
   (Assuming the command is run from the project root directory)
 
 - **Visual Tools**: [DB Browser for SQLite](https://sqlitebrowser.org/) or VSCode extensions like SQLite Viewer

services/backend/README.md

@@ -84,10 +84,12 @@ services/backend/
 The `services/backend/persistent_data/` directory is designated for storing all data that needs to persist across application restarts or deployments.
 
 **Purpose:**
+
 - To provide a single, consistent location for all persistent backend data.
 - When developing backend features that require data persistence (e.g., database files, configuration files that should not be in version control but are generated/modified at runtime), use this directory exclusively.
 
 **Examples of data stored here:**
+
 - SQLite database file (e.g., `persistent_data/database/deploystack.db`)
 - Database selection configuration (e.g., `persistent_data/db.selection.json`)
 

services/backend/SECURITY.md

@@ -12,19 +12,19 @@ We will acknowledge receipt of your vulnerability report promptly and work with
 
 User passwords are never stored in plaintext. We employ a strong, adaptive hashing algorithm to protect user credentials.
 
--   **Algorithm:** We will use `argon2id`, which is a part of the Argon2 family of algorithms (Argon2id is generally recommended as it provides resistance against both side-channel attacks and GPU cracking attacks).
--   **Salt Generation:** A unique, cryptographically secure salt is automatically generated for each user's password by the `argon2` library at the time of account creation or password change. This salt is then stored as part of the resulting hash string.
--   **Parameters:** We use appropriate parameters for `argon2` (e.g., memory cost, time cost, and parallelism) to ensure that the hashing process is computationally intensive, making brute-force attacks significantly more difficult. These parameters are chosen to balance security with acceptable performance on our servers and may be adjusted based on hardware improvements over time.
--   **Verification:** During login, the provided password and the stored salt (extracted from the hash string) are used to re-compute the hash. This newly computed hash is then compared against the stored hash in a constant-time manner (handled by the `argon2` library's verify function) to help prevent timing attacks.
+- **Algorithm:** We will use `argon2id`, which is a part of the Argon2 family of algorithms (Argon2id is generally recommended as it provides resistance against both side-channel attacks and GPU cracking attacks).
+- **Salt Generation:** A unique, cryptographically secure salt is automatically generated for each user's password by the `argon2` library at the time of account creation or password change. This salt is then stored as part of the resulting hash string.
+- **Parameters:** We use appropriate parameters for `argon2` (e.g., memory cost, time cost, and parallelism) to ensure that the hashing process is computationally intensive, making brute-force attacks significantly more difficult. These parameters are chosen to balance security with acceptable performance on our servers and may be adjusted based on hardware improvements over time.
+- **Verification:** During login, the provided password and the stored salt (extracted from the hash string) are used to re-compute the hash. This newly computed hash is then compared against the stored hash in a constant-time manner (handled by the `argon2` library's verify function) to help prevent timing attacks.
 
 This approach ensures that even if the database were compromised, recovering the original passwords would be computationally infeasible.
 
 ## Session Management
 
 User sessions are managed using `lucia-auth`.
 
--   Session identifiers are cryptographically random and stored in secure, HTTP-only cookies to prevent XSS attacks from accessing them.
--   Sessions have defined expiration times (both active and idle timeouts) to limit the window of opportunity for session hijacking.
+- Session identifiers are cryptographically random and stored in secure, HTTP-only cookies to prevent XSS attacks from accessing them.
+- Sessions have defined expiration times (both active and idle timeouts) to limit the window of opportunity for session hijacking.
 
 ## Data Validation