Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

[Security] Use random salts for new password hashes, with backward-compatible migration

Aperta
  • Qualcosa non va?
#130 1 commento 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

@Taha254511 ci sta già lavorando.

Dal 18/10/2026.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
45/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
python
Ambito
authentication, backend, security

Direzione di ricerca

Start with the referenced hashing and verification functions in src/worker.py, then read MIGRATION.md for existing Django-hash support and the authentication flows. Find the tests covering registration, login, password reset and change, and run them before changing anything. Done means new hashes use random salts and a self-describing format, while successful legacy authentication upgrades hashes without breaking supported flows.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Summary

src/worker.py currently derives each application's PBKDF2 salt deterministically as SHA-256(_PEPPER || username), where _PEPPER is a constant committed to the repository.
The resulting application-specific password hash is stored as a Base64-encoded digest without recording the algorithm or its parameters.
Because _PEPPER is public, it cannot provide the protection expected from a confidential secret pepper.

This issue proposes improving password-storage practices while preserving compatibility with existing accounts. It does not claim evidence of a security breach.

Current limitations

  • The salt is deterministic rather than randomly generated for each password hash.
  • _PEPPER is committed to the repository and therefore cannot be treated as a confidential secret.
  • The current application-specific hash format does not record its algorithm or parameters.
  • The current application's legacy hash verification uses ordinary == comparison rather than constant-time comparison.

Proposed solution

  1. Generate a cryptographically random salt for each newly created password hash.
  2. Store new hashes in a self-describing format containing the algorithm, iteration count, salt, and derived hash. The existing pbkdf2_sha256$iterations$salt$hash format handled by _verify_django_password() can be reused.
  3. Preserve a dedicated verification path for the existing application-specific Base64-only hashes. Retain _PEPPER only as long as it is needed to verify those hashes. New hashes must not depend on this committed value.
  4. Use _hmac.compare_digest() when comparing derived hashes, including the existing application-specific legacy hashes. Preserve the constant-time comparison already used by _verify_django_password().
  5. Upgrade existing application-specific hashes after successful authentication so users do not need to reset their passwords solely because of the format change.
  6. Continue supporting existing Django-format password hashes. Rehash those only when required by the agreed password-hashing policy.

Out of scope

  • Introducing a new secret pepper loaded from a Wrangler secret. This requires passing the appropriate runtime configuration to the hashing functions and can be considered separately.
  • Changing the PBKDF2 iteration count. Worker CPU limits should be evaluated before changing the work factor.
  • Changing token handling or login response formats.
  • Logging passwords, derived hashes, or other sensitive authentication data.

Acceptance criteria

  • New password hashes use cryptographically random salts.
  • Stored hashes include the algorithm and parameters necessary for verification.
  • Correct passwords are accepted and incorrect passwords are rejected.
  • Existing application-specific hashes and supported legacy Django hashes remain verifiable.
  • Existing application-specific hashes are upgraded after successful authentication.
  • New hashes do not depend on any confidential value committed to source control.
  • Legacy hash verification uses constant-time comparison where appropriate.
  • Automated tests cover hash generation, unique salts, successful and failed verification, legacy compatibility, and migration.
  • Registration, login, password-reset, and password-change flows continue to work.

Manual verification

  • Register a new user and confirm that the stored hash uses the new format with a randomly generated salt.
  • Sign in with an account using the existing application-specific hash format and confirm that the hash is upgraded.
  • Verify that supported legacy Django-format hashes continue to work.
  • Confirm that an incorrect password is rejected.
  • Reset a password and confirm that the new password works while the old password no longer works.

Backward compatibility

Changing the salt derivation directly would invalidate existing application-specific password hashes.
The implementation must retain a separate verification path for the existing format and migrate hashes only after successful authentication.
The legacy constant must not be removed while accounts still depend on it unless an appropriate migration or account-recovery strategy has been agreed upon.

References

Lingua principale
HTML
Stelle
3
Fork
28
Merge medio
17h 41m
PR unite (30g)
7

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di alphaonelabs/learn

Tutte le issue di alphaonelabs/learn

Issue simili

Altre issue su Security

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.