(tooling-agents) branch main updated: ASVS audit: 6.7.2.md (redacted)

[as...@apache.org]

This is an automated email from the ASF dual-hosted git repository.

asf-tooling pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/tooling-agents.git


The following commit(s) were added to refs/heads/main by this push:
     new 29b7e18  ASVS audit: 6.7.2.md (redacted)
29b7e18 is described below

commit 29b7e18e2f2e10b904b8ce2c39293c664dbbdd49
Author: ASF Tooling Team <ro...@apache.org>
AuthorDate: Tue May 5 14:09:19 2026 +0200

    ASVS audit: 6.7.2.md (redacted)
---
 ASVS/reports/steve/v3/d0aa7e9/all/6.7.2.md | 88 ++++++++++++++++++++++++++++++
 1 file changed, 88 insertions(+)

diff --git a/ASVS/reports/steve/v3/d0aa7e9/all/6.7.2.md b/ASVS/reports/steve/v3/d0aa7e9/all/6.7.2.md
new file mode 100644
index 0000000..bbb4d8e
--- /dev/null
+++ b/ASVS/reports/steve/v3/d0aa7e9/all/6.7.2.md
@@ -0,0 +1,88 @@
+# Security Audit Report: ASVS 6.7.2
+
+## Executive Summary
+
+| Field | Value |
+|-------|-------|
+| **Repository** | apache/steve/v3 |
+| **Audit Date** | May 05, 2026 |
+| **Auditor** | Tooling Agents (bundled-pass mode) |
+| **ASVS Requirement** | ASVS 6.7.2 |
+| **Files Analyzed** | 6 relevant / 49 total |
+| **Files Skipped** | 12 |
+
+**Requirement description:** Verify that the challenge nonce is at least 64 bits in length, and statistically unique or unique over the lifetime of the cryptographic device.
+
+### Findings Overview
+
+| Severity | Count |
+|----------|-------|
+| 🔴 Critical | 0 |
+| 🟠 High | 0 |
+| 🟡 Medium | 0 |
+| 🟢 Low | 0 |
+
+---
+
+## ASVS-6.7.2: Cryptographic Authentication Mechanism - Challenge Nonce
+
+### Findings for 6.7.2
+
+The codebase does not implement challenge-response cryptographic authentication (e.g., FIDO/WebAuthn, smart cards). The authentication is handled externally via `asfquart.auth`. However, the system does generate nonce-like values (salts) used in its vote token generation scheme that can be assessed against this requirement's principles.
+
+No findings detected specific to challenge nonces for cryptographic authentication devices, as this mechanism is not implemented in the audited code.
+
+**Note on salt adequacy**: The system generates 128-bit (16-byte) salts using `secrets.token_bytes(16)` which exceeds the 64-bit minimum requirement. These are statistically unique given the CSPRNG source.
+
+### Security Controls Inventory for 6.7.2
+
+| Control | Location | Status |
+|---------|----------|--------|
+| Salt generation (128 bits) | `v3/steve/crypto.py:36-37` (`gen_salt()`) | Exceeds 64-bit requirement |
+| CSPRNG source (`secrets.token_bytes`) | `v3/steve/crypto.py:37` | Cryptographically secure |
+| Unique salt per mayvote entry | `v3/steve/election.py:116-133` (`add_salts()`) | Each person/issue pair gets unique salt |
+
+### Positive Patterns for 6.7.2
+
+- `secrets.token_bytes(16)` provides 128 bits of cryptographic randomness — well above the 64-bit minimum
+- Each voter-issue pair receives a unique salt, ensuring statistical uniqueness
+- The `SALT_LEN = 16` constant is clearly defined and consistently used
+- Fisher-Yates shuffle uses `secrets.randbelow()` for cryptographically-secure randomization
+
+---
+
+
+
+## Cross-cutting Architecture Observations
+
+1. **Single Trust Boundary**: The application places complete trust in the `asfquart` authentication framework. There is no defense-in-depth for authentication - if the framework is bypassed, all controls fail simultaneously.
+
+2. **Cryptographic Architecture vs. Authentication Architecture Mismatch**: The election voting system has sophisticated cryptographic protections (Argon2 hashing, per-voter salts, Fernet encryption, anti-tamper detection), but the authentication and authorization layer is incomplete with numerous `### check authz` placeholder comments.
+
+3. **No Separation of Duties**: The same `R.committer` role can both manage elections and vote in them. There is no enforcement that the election owner cannot also modify votes or bypass the anti-tamper mechanism.
+
+4. **CSRF Protection Gap**: The placeholder CSRF token (`'placeholder'`) means that even with proper IdP integration, session-based attacks remain possible across all POST endpoints and the GET-based state-changing endpoints (`/do-open/`, `/do-close/`).
+
+5. **Opaque Authentication Dependencies**: The security posture of the application is heavily dependent on the `asfquart` library, which is not included in the audit scope. The application cannot be fully assessed for ASVS 6.8.x requirements without visibility into this dependency.
+
+6. **Authorization is Role-Based Only**: The system checks if a user is a "committer" or "pmc_member" but does not check if they are the *owner* of a specific election or have been specifically authorized for it. Any committer can manage any election.
+
+## Cross-cutting Recommendations
+
+### Immediate (Critical Priority)
+1. **Implement CSRF protection**: Replace the placeholder token with a real CSRF mechanism. This affects all POST endpoints and the GET-based state-changing endpoints.
+2. **Convert state-changing GET endpoints to POST**: `/do-open/<eid>` and `/do-close/<eid>` must not use GET for irreversible operations.
+3. **Implement authorization checks**: Replace all `### check authz` placeholders with actual ownership/permission verification before allowing election management operations.
+
+### Short-term (High Priority)
+4. **Add authentication strength verification**: Capture and validate `acr`, `amr`, and `auth_time` from the IdP for sensitive operations (election open/close, vote submission).
+5. **Namespace user identities by IdP**: Add an IdP identifier to the `person.pid` to prevent future identity collision if multiple IdPs are supported.
+6. **Document authentication framework requirements**: Create explicit documentation of what `asfquart.auth` must verify (signature validation, replay prevention, token expiry) as a contractual interface.
+7. **Add database integrity protection**: Implement an HMAC or signature over the `opened_key` to detect unauthorized modification at the database level.
+
+### Long-term (Architectural)
+8. **Implement step-up authentication**: For critical operations (opening/closing elections), require re-authentication or MFA verification.
+9. **Add audit logging for authentication events**: Log authentication method, strength, and time for security monitoring.
+10. **Consider database encryption**: Protect the SQLite database at rest to prevent direct modification of cryptographic material.
+11. **Implement proper secret management**: The cryptographic keys and salts should be managed according to the "Secret Management" principles referenced in the ASVS section description, potentially using a dedicated key management service.
+        
\ No newline at end of file


---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@tooling.apache.org
For additional commands, e-mail: commits-help@tooling.apache.org