Add PEPPER to password handling for improved security

[JonanOribe]

Introduces a PEPPER value from config and appends it to passwords during both admin user creation and login authentication. This enhances password security by making hashes more resilient to attacks.

[smittix]

Thanks for the contribution! The pepper concept is good for defense-in-depth, but there are two issues that need to be addressed before merging:

1. Hardcoded Default Pepper

PEPPER = _get_env('PEPPER', '7aJBLRSimPO0l6Wkfic8YhO3PPqwPwD7oikTfK4TYjzIFxS4Tk')

A pepper's security comes from being secret and not in the source code. With a hardcoded default, anyone with access to the repo has the pepper, defeating its purpose.

Suggested fix: Either:

• Require explicit configuration (no default) and fail startup if not set
• Generate a random pepper on first run and store it in the database or a local file outside the repo
• Document that users must set a custom PEPPER env var in production

2. Breaking Change for Existing Accounts

After this change, existing admin accounts will fail to authenticate because:

• Existing password hash = hash(password)
• New login check = hash(password + pepper)

These won't match.

Suggested fix: Add a migration path:

• Option A: On first run after upgrade, detect missing pepper and rehash existing passwords
• Option B: Add a one-time migration command/script
• Option C: At minimum, document that users need to reset their admin password after upgrading

---

Once these are addressed, happy to merge!

[JonanOribe]

Thank you for the detailed feedback. These are excellent points regarding security and the upgrade path. I will be implementing the following changes to address them:

1. Removal of Hardcoded Pepper & Secure Storage Strategy

I will remove the hardcoded default pepper to ensure the secret is never part of the source code. I will adopt the following approach:

• Fail-fast Initialization: I’ll modify the startup logic to require an explicit PEPPER environment variable. The application will throw a ConfigurationError and refuse to start if it is missing.

• Storage Outside the Database: I will document that the pepper must be stored in the OS environment or a local config file outside the web root. I am avoiding the database storage option because if the DB is ever compromised, the pepper would be stolen alongside the hashes, defeating the defense-in-depth purpose. This approach ensures a proper Separation of Secrets and works consistently across Linux and macOS. Furthermore, in the future, we could use this PEPPER as a Master Secret for an HKDF (Key Derivation Function). This would allow us to derive unique, cryptographically independent keys for different purposes, such as one for password hashing and another for encrypting sensitive SDR recordings or private messages. This way, even if one sub-key were somehow leaked, the others remain secure. By keeping the root secret outside the database, we ensure that even in the event of a full data breach, the most sensitive content remains encrypted and unreadable without the server-side secret

2. Migration Path for Existing Accounts

To handle the transition without locking out current users, I will implement a "Lazy Rehash" strategy:

• Dual Verification Logic: The authentication process will first attempt to verify the password using hash(password + pepper).

• On-the-fly Migration: If that fails, it will fallback to the legacy hash(password). If the legacy check succeeds, the system will automatically re-hash the password with the new pepper and update the database record immediately.

• Documentation: I will also add a note to the changelog/migration guide so users are aware of this security hardening.

To be honest, I left the PEPPER hardcoded, much like the default database username and password, assuming that the first thing any user would do after cloning the repo for deployment is customize these values. However, I agree that your approach is much cleaner and more secure.

I will push these updates as soon as they are ready.

[JonanOribe]

I've implemented the requested changes. This includes both the UV requirements and functionality, as well as Docker and setup.sh. I've tested it, but please review it carefully in case you find anything missing, as there are many possible combinations and I don't want to have overlooked anything.

I've also added the missing dependencies to the .toml file after the latest updates.