加密数据存储算法评审请求：自制类KeePass命令行工具安全性核查

Hey there! 👋 Building a KeePass-like CLI tool for fun is such a great way to dive into applied cryptography—love that you're prioritizing security reviews upfront. Let's break down each of your evaluation areas with actionable checks and best practices:

Start by hunting for these common (but critical) security gaps:

• Hardcoded Secrets: Scan your code for any hardcoded keys, salts, or default passwords. Even accidental hardcoding can turn a secure tool into a ticking time bomb.
• Insecure Randomness: Ensure you're using cryptographically secure random number generators (CSPRNGs) for salts, IVs, and any key material. For example, in Python use secrets.token_bytes() instead of random.getrandbits().
• Plaintext Data Exposure: Verify that sensitive data (user passwords, plaintext entries, decrypted files) never gets logged, written to temporary files, or left in memory longer than necessary. In lower-level languages like C/C++, overwrite memory after use; in higher-level languages, avoid unnecessary data copies.
• Missing Authentication: Encrypted data should include a message authentication code (MAC) or use an AEAD algorithm (see below) to prevent tampering. Without this, an attacker could modify ciphertext and cause unexpected behavior during decryption.
• Weak Key Storage: Never store derived keys in plaintext. All key material should be generated on-the-fly from the user's password and stored salts, then discarded immediately after use.

Stick to industry-standard, audited algorithms to avoid reinventing the wheel (and making costly mistakes):

• Encryption: Use Authenticated Encryption with Associated Data (AEAD) algorithms exclusively. Top choices are:
  • AES-256-GCM: The gold standard for symmetric encryption, widely supported and efficient.
  • ChaCha20-Poly1305: A great alternative for devices with weak AES hardware acceleration.
    Avoid older modes like AES-CBC or AES-ECB—they don't provide built-in integrity checks and are easy to misconfigure.
• Key Derivation: Use a slow, memory-hard KDF to turn user passwords into strong encryption keys:
  • Argon2id: The winner of the Password Hashing Competition, balances CPU, memory, and parallelism resistance (KeePass uses this by default).
  • bcrypt: A reliable older option, though less resistant to GPU attacks than Argon2.
  • PBKDF2-HMAC-SHA256: If you need maximum compatibility, use at least 1,000,000 iterations (2024 baseline).
• Salt & IV Best Practices:
  • Salts: Generate a unique 16+ byte salt per user/database (not per entry). Store it alongside the ciphertext (no need to encrypt it).
  • IVs: Generate a unique 12-byte IV (for AES-GCM) or 16-byte IV (for ChaCha20) for every encryption operation. Again, store it with the ciphertext.

Keep your code lean and maintainable by checking for these red flags:

• Duplicate Crypto Logic: If you're copying encryption/decryption or KDF code across multiple functions, wrap it into a single, reusable module or class. This reduces the chance of inconsistent implementations.
• Unnecessary Dependencies: Avoid using obscure or unmaintained cryptography libraries. Stick to well-audited options like cryptography (Python), BouncyCastle (Java/C#), or libsodium (C).
• Redundant Data Storage: Don't store redundant information in your database. For example, there's no need to store both the KDF salt and a separate password hash—use the KDF-derived key to verify the password (e.g., by decrypting a known "magic value" stored in the database).

Your tool's ability to resist brute-force attacks depends mostly on KDF strength and password hygiene:

• KDF Parameter Tuning: Adjust your KDF parameters to make password guessing as slow as possible without frustrating users. For Argon2id, start with:
  • Memory cost: 1GB (1024 MiB)
  • Iterations: 3
  • Parallelism: 4
    Test these on your target hardware—if decryption takes longer than 1-2 seconds, dial back the memory or iterations slightly.
• Password Strength Guidance: Add a simple password strength checker (e.g., check for minimum length, character variety) or prompt users to use passphrases (which are easier to remember and harder to brute-force than short complex passwords).
• Local Rate Limiting: Even for a local tool, add a small delay (e.g., 1 second) after failed decryption attempts. This slows down automated brute-force scripts without impacting legitimate users.
• Database Obfuscation: While not a replacement for strong KDFs, you can add minor obfuscation (e.g., random padding at the start of the database file) to make it harder for attackers to identify the file format and target it with specialized tools.

You mentioned an encryption workflow but didn't share the specific steps. If you can outline your process (e.g., "User password → Argon2id with salt → AES-GCM encryption → store salt + IV + ciphertext + tag"), I can provide targeted feedback on whether it follows security best practices and where it might be improved.

内容的提问来源于stack exchange，提问作者Cristiano Coelho