urVault

A lightweight, self-hostable password policy & security engine for teams.

Stop shipping regex-based password rules. Give your product real, breach-aware password validation — without sending user data to a third party.

---

The Problem

Every product with a signup form eventually needs to answer: "how strong is this password, and has it been breached before?"

Today, teams solve this one of three ways:

• Roll their own rules — "8+ characters, 1 uppercase, 1 symbol" — rules that are well known to be weak and that frustrate users without actually stopping weak passwords like Password1!.
• Wire it up themselves — pull in a strength-scoring library and the Have I Been Pwned API individually, then rebuild the same validation logic in every project.
• Buy a full auth platform (Auth0, Okta, etc.) just to get password policy enforcement — massive overkill when all you need is the validation layer, not an entire identity system.

There's no small, dedicated, self-hostable tool that just does password policy well — and proves it, for teams who need to show compliance.

What urVault Is

urVault is a password policy engine, not a password manager. It never stores or transmits real user passwords. It exists to answer one question well: "does this password meet our policy, and can we prove it?"

It's built for teams who need:

• Real, entropy-based strength scoring (not regex)
• Breach detection without exposing user data
• A record they can point to during a security audit

Core Features

1. Strength Evaluation

Uses zxcvbn (the entropy-based model originally built at Dropbox) instead of arbitrary complexity rules. Returns:

• A strength score (0–4)
• Estimated offline crack time
• Actionable feedback when a password is weak

2. Breach Detection (Privacy-Safe)

Checks passwords against the Have I Been Pwned database using k-anonymity — only the first 5 characters of a SHA-1 hash are ever sent over the network. The real password, and even its full hash, never leaves the machine running urVault.

3. Secure Hashing

Once a password passes policy, urVault hashes it with bcrypt (salted, industry-standard) as a reference implementation of what to store — urVault itself doesn't retain the plaintext.

4. Memory Hygiene ("The Destructor")

Plaintext passwords are handled as mutable byte arrays, explicitly overwritten after use, and released via del + gc.collect(), wrapped in a finally block so cleanup runs even on failure.

Honesty note: In a garbage-collected language like Python, this is a defense-in-depth measure, not a cryptographic guarantee — CPython string interning, buffer reuse, and OS-level memory/swap behavior mean true secure erasure isn't fully controllable from pure Python. urVault documents this clearly rather than overclaiming.

5. Policy-as-Code

Teams define their own rules in a config file — minimum score, banned word lists, breach-check enforcement — instead of hardcoded logic. Policies are versioned, so a team can show what their policy was and when it changed.

6. Compliance Mapping

Policies can be mapped to named standards — starting with NIST 800-63B, which explicitly recommends breach-checking over forced complexity rules. This turns urVault from "a checker" into "an auditable compliance control."

7. Audit Trail

Every validation event (pass/fail, policy version, reason) is logged, exportable as a report — the artifact a team hands to a SOC 2 or ISO 27001 auditor as proof they enforce password policy.

What urVault Is Not

• Not a password manager. It never stores end-user credentials for retrieval.
• Not a full auth/identity platform. No login flows, sessions, or user accounts — it's a validation layer that sits in front of whatever auth system a team already has.
• Not a black box. The core engine is open source, so a security team can read exactly what it does with a password before trusting it.

Roadmap

Phase	Description	Status
0 — Core Engine	Importable Python module: strength scoring, HIBP check, bcrypt hashing, memory hygiene	In progress
1 — API Layer	Flask-based REST API (/validate), config-driven policy (policy.yaml), NIST 800-63B compliance profile	Planned
2 — Multi-Tenant	API keys per project, SQLite-backed policy storage, per-org audit logs	Planned
3 — Production Packaging	Docker self-host image, minimal admin dashboard, rate limiting, exportable compliance reports	Planned

Business Model (Open-Core)

• Core engine: open source (MIT). Self-hostable, free, auditable — this is the trust signal a security-conscious team needs before adopting a policy tool from an unknown vendor.
• Hosted/managed layer: paid. Dashboard, managed audit logs, SLA, support — for teams that don't want to run infrastructure themselves.
• Compliance add-ons: paid, even for self-hosters. Auto-generated compliance reports, SSO for the admin dashboard, multi-org management.

Tech Stack

• Language: Python 3.8+
• Strength scoring: zxcvbn
• Hashing: bcrypt
• Breach detection: Have I Been Pwned API (k-anonymity)
• Secure input: getpass
• API layer (Phase 1+): Flask
• Storage (Phase 2+): SQLite → Postgres

Security Principles

• Plaintext passwords are never logged, stored, or transmitted in full — only scores, hash prefixes (for breach checks), and pass/fail outcomes ever persist.
• Self-hosting is a first-class option, not an afterthought — some teams will never send password-related data to a third party, and urVault is built to respect that.
• Responsible disclosure: security issues can be reported via [contact method to be added].

Status

This project is under active early development. The core engine (Phase 0) is being built first as a standalone, well-documented module before any API or storage layer is added.