(tooling-agents) branch main updated: ASVS audit: 6.2.12.md (redacted) [source: apache/steve/v3 @ d0aa7e9]

[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 ec15f40  ASVS audit: 6.2.12.md (redacted) [source: apache/steve/v3 @ d0aa7e9]
ec15f40 is described below

commit ec15f40bede536d5ee9252805cd9f3dbbe42547d
Author: ASF Tooling Team <ro...@apache.org>
AuthorDate: Tue May 5 22:57:07 2026 +0200

    ASVS audit: 6.2.12.md (redacted) [source: apache/steve/v3 @ d0aa7e9]
---
 ASVS/reports/steve/v3/d0aa7e9/all/6.2.12.md | 100 ++++++++++++++++++++++++++++
 1 file changed, 100 insertions(+)

diff --git a/ASVS/reports/steve/v3/d0aa7e9/all/6.2.12.md b/ASVS/reports/steve/v3/d0aa7e9/all/6.2.12.md
new file mode 100644
index 0000000..cc4d3d4
--- /dev/null
+++ b/ASVS/reports/steve/v3/d0aa7e9/all/6.2.12.md
@@ -0,0 +1,100 @@
+# Security Audit Report: ASVS 6.2.12
+
+## Executive Summary
+
+| Field | Value |
+|-------|-------|
+| **Repository** | apache/steve/v3 |
+| **Audit Date** | May 05, 2026 |
+| **Auditor** | Tooling Agents (bundled-pass mode) |
+| **ASVS Requirement** | ASVS 6.2.12 |
+| **Files Analyzed** | 5 relevant / 49 total |
+| **Files Skipped** | 12 |
+
+**Requirement description:** Verify that passwords submitted during account registration or password changes are checked against a set of breached passwords.
+
+### Findings Overview
+
+| Severity | Count |
+|----------|-------|
+| 🔴 Critical | 0 |
+| 🟠 High | 0 |
+| 🟡 Medium | 0 |
+| 🟢 Low | 0 |
+
+---
+
+## ASVS-6.2.12: Breached Password Checking
+
+### Findings for 6.2.12
+
+No local password creation, registration, or password change operations exist in the audited codebase. There is no endpoint that accepts a user-chosen password. Authentication is entirely delegated to ASF's external authentication system via `asfquart.auth` and `asfquart.session`.
+
+**Evidence of absence**: A comprehensive search of all provided source files reveals:
+- No `/register`, `/signup`, `/change-password`, or equivalent endpoints
+- No password field in the database schema
+- No password hashing (bcrypt, argon2 for passwords, etc.) — the crypto module is used exclusively for election vote encryption
+- No integration with Have I Been Pwned (HIBP) or any breached password database
+
+The `queries.yaml` `person` section only supports:
+```yaml
+person:
+    c_add_person: |
+        INSERT INTO person VALUES (?, ?, ?)
+        ON CONFLICT DO UPDATE SET
+            name=excluded.name,
+            email=excluded.email
+```
+
+This inserts `pid`, `name`, and `email` — no password parameter.
+
+**Determination**: Not applicable to this codebase as-is. The external auth provider must satisfy this requirement.
+
+### Security Controls Inventory for 6.2.12
+
+| Control | Location | Status |
+|---------|----------|--------|
+| Breached password check (HIBP/similar) | Not present | N/A (no local passwords) |
+| Password registration validation | Not present | N/A |
+| Password change validation | Not present | N/A |
+
+### Positive Patterns for 6.2.12
+
+- No local credential storage means no risk of accepting breached passwords within this application's boundary.
+
+---
+
+
+
+## Cross-cutting Architecture Observations
+
+1. **Authentication Architecture**: This application exclusively uses external authentication via `asfquart.auth` (ASF's authentication infrastructure). All ASVS 6.2.x password requirements are implicitly delegated to this external provider. The application has **zero** local password management functionality.
+
+2. **Future Risk**: The codebase contains explicit comments (lines 19-22 of `pages.py`) indicating that the current ASF-only authentication model is not intended to be the final solution. When local authentication is added, ALL password security controls (6.2.2 through 6.2.12) will need to be implemented from scratch.
+
+3. **Shared Responsibility Model**: In the current architecture, password security is a shared responsibility:
+   - **External auth provider (ASF)**: Responsible for password creation, storage, validation, change, and all ASVS 6.2.x controls
+   - **This application**: Responsible only for properly integrating with the external auth system (session management, auth requirement enforcement)
+
+4. **No Credential Storage**: The database schema (`person` table) intentionally stores no credentials, only identity information (`pid`, `name`, `email`). This is a clean separation of concerns.
+
+5. **Session Management**: While passwords aren't managed locally, the application does handle sessions via `asfquart.session`. The session handling appears to properly read authenticated state from the external provider.
+
+## Cross-cutting Recommendations
+
+### Immediate (if deploying with local auth)
+- **Implement all ASVS 6.2.x controls**: If the application ever moves away from external-only auth, a complete password management module must be developed including:
+  - Password change endpoint requiring current password (6.2.2, 6.2.3)
+  - Top 3000+ common password blocklist (6.2.4)
+  - No character composition rules (6.2.5)
+  - Context-specific word list (election terms, application name, etc.) (6.2.11)
+  - Integration with HIBP or similar breached password database (6.2.12)
+
+### Short-term
+- **Document authentication delegation**: Create explicit documentation stating which ASVS controls are satisfied by the external authentication provider (ASF's system), and obtain assurance that the provider meets Level 2 requirements.
+- **Verify external provider compliance**: Confirm that ASF's authentication system implements breached password checking, common password rejection, and context-specific word blocking.
+
+### Long-term
+- **Design local auth module**: If multi-deployment scenarios are pursued (as comments suggest), design the password management module with all ASVS 6.2.x requirements from the start, using libraries like `zxcvbn` for strength estimation and the HIBP k-Anonymity API for breached password checking.
+- **Configuration-driven auth**: Implement a pluggable authentication architecture that can switch between external providers and local credential management, with password security controls automatically enabled when local auth is active.
+        
\ 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