Mailman 3 March 2026 - Cryptography-dev

Help needed
by LUCKMAN WORLD March 20, 2026

March 20, 2026

Hello, I’m currently building a web application that includes user authentication (signup/login) with email verification. I’m using bcrypt for password hashing and considering additional safeguards around verification codes and input validation. I came across a discussion regarding PBKDF2 edge cases (such as invalid iteration values causing unexpected behavior), and it made me reconsider how much validation should be handled at the application level versus relying on library safeguards. My questions are: 1. What are the recommended best practices for password hashing in modern web applications? 2. Should developers always enforce strict validation on cryptographic parameters (e.g., iteration counts), even when using well-maintained libraries? 3. Are there preferred approaches for securely handling verification codes (email/SMS) in terms of storage and expiration? I would appreciate any guidance or references. Thank you.

1 0

Help needed
by LUCKMAN WORLD March 20, 2026

March 20, 2026

Hello, I’m currently building a web application that includes user authentication (signup/login) with email verification. I’m using bcrypt for password hashing and considering additional safeguards around verification codes and input validation. I came across a discussion regarding PBKDF2 edge cases (such as invalid iteration values causing unexpected behavior), and it made me reconsider how much validation should be handled at the application level versus relying on library safeguards. My questions are: 1. What are the recommended best practices for password hashing in modern web applications? 2. Should developers always enforce strict validation on cryptographic parameters (e.g., iteration counts), even when using well-maintained libraries? 3. Are there preferred approaches for securely handling verification codes (email/SMS) in terms of storage and expiration? I would appreciate any guidance or references. Thank you.

1 0

Help needed
by LUCKMAN WORLD March 20, 2026

March 20, 2026

Hello, I’m currently building a web application that includes user authentication (signup/login) with email verification. I’m using bcrypt for password hashing and considering additional safeguards around verification codes and input validation. I came across a discussion regarding PBKDF2 edge cases (such as invalid iteration values causing unexpected behavior), and it made me reconsider how much validation should be handled at the application level versus relying on library safeguards. My questions are: 1. What are the recommended best practices for password hashing in modern web applications? 2. Should developers always enforce strict validation on cryptographic parameters (e.g., iteration counts), even when using well-maintained libraries? 3. Are there preferred approaches for securely handling verification codes (email/SMS) in terms of storage and expiration? I would appreciate any guidance or references. Thank you.

1 0

[Security] cryptography — PBKDF2HMAC(iterations=0) triggers uncatchable PanicException (DoS)
by Amartya Jha March 10, 2026

March 10, 2026

To the Python Cryptographic Authority / cryptography maintainers, I am a security researcher at CodeAnt AI. I have discovered a denial-of-service vulnerability in the cryptography package's PBKDF2HMAC key derivation function. When iterations=0 is passed, the Rust backend raises a pyo3_runtime.PanicException, a direct subclass of BaseException, not Exception — which silently escapes all standard Python exception handlers and can crash the application process. Package: cryptography Affected Versions: All modern versions (36.x through 46.x) using the PyO3/Rust backend Tested Version: 46.0.5 CVSS: 5.3 MEDIUM (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L) CWE: CWE-703 (Improper Check or Handling of Exceptional Conditions), CWE-20 (Improper Input Validation) --- What is the Issue? PBKDF2HMAC.__init__() in cryptography/hazmat/primitives/kdf/pbkdf2.py stores the iterations parameter directly without any bounds validation: def __init__(self, algorithm, length, salt, iterations, backend=None): ... self._iterations = iterations # stored directly, no bounds check When derive() is called with iterations=0, this value is passed to the Rust layer in src/rust/src/backend/kdf.rs:30, which calls .unwrap() on the OpenSSL error rather than propagating it via map_err. This causes a Rust panic: thread '<unnamed>' panicked at src/rust/src/backend/kdf.rs:30:87: called `Result::unwrap()` on an `Err` value: ErrorStack([Error { code: 478150779, library: "Provider routines", function: "kdf_pbkdf2_set_ctx_params", reason: "invalid iteration count", file: "providers/implementations/kdfs/pbkdf2.c", line: 305 }]) PyO3 surfaces Rust panics as pyo3_runtime.PanicException. This class inherits from BaseException, NOT Exception: pyo3_runtime.PanicException → BaseException → object --- What is the Impact? 1. Process crash via DoS: Any application that accepts a user-controlled iterations value and passes it to PBKDF2HMAC (e.g., via JSON API payload, config file, URL parameter, or database-stored value) can be crashed by a single request with iterations=0. 2. Silent bypass of all error handling: The universally expected Python idiom "except Exception:" does NOT catch BaseException subclasses. Every standard web framework error handler, request handler, and try/except block in the application stack silently fails to catch this crash: try: kdf = PBKDF2HMAC(algorithm=hashes.SHA256(), length=32, salt=b"salt", iterations=0) result = kdf.derive(b"password") except Exception as e: print("Caught:", e) # <-- NEVER REACHED 3. Contrast with iterations=-1: Passing -1 correctly raises OverflowError (a subclass of Exception) and IS catchable. Only iterations=0 hits the Rust panic path. --- Proof of Concept: from cryptography.hazmat.primitives.kdf.pbkdf2 import PBKDF2HMAC from cryptography.hazmat.primitives import hashes kdf = PBKDF2HMAC(algorithm=hashes.SHA256(), length=32, salt=b"salt", iterations=0) print("__init__ passed: no error raised here") try: result = kdf.derive(b"password") except Exception as e: print("Caught (Exception):", e) # NEVER REACHED Realistic attack vector (API endpoint accepting PBKDF2 parameters): @app.post("/derive-key") async def derive_key(params: KDFParams): try: kdf = PBKDF2HMAC( algorithm=hashes.SHA256(), length=params.key_length, salt=params.salt.encode(), iterations=params.iterations # user-controlled! ) return {"key": kdf.derive(params.password.encode()).hex()} except Exception as e: raise HTTPException(status_code=400, detail=str(e)) # PanicException bypasses the except Exception block above --- Recommended Fix: Option 1 — Python-level validation (fastest fix): def __init__(self, algorithm, length, salt, iterations, backend=None): ... if not isinstance(iterations, int) or iterations < 1: raise ValueError( "iterations must be a positive integer, got {!r}".format(iterations) ) self._iterations = iterations Option 2 — Rust-level fix (proper long-term fix): Replace .unwrap() in src/rust/src/backend/kdf.rs:30 with proper error propagation using map_err so that OpenSSL errors surface as catchable Python exceptions via PyO3's error conversion. Both fixes should be applied: the Python-level check as a fast guard with a clear error message, and the Rust-level fix to make the entire error path robust. --- I am happy to provide a complete test harness, coordinate a patch review, or adjust the disclosure timeline. --- Researcher: CodeAnt AI Security Research Team, part of https://www.codeant.ai/ Contact: securityresearch(a)codeant.ai

2 1