Whitepaper
Architectural Whitepaper: EZPD Password
The Metadata-Driven, Multi-Cloud Fragmented Secret Regeneration Architecture
Last Updated : October 16, 2026
1. Executive Summary & The Core Innovation
Traditional password managers face an inherent systemic vulnerability: they function as centralized vaults storing encrypted master blobs (ciphertexts) of actual passwords. If a cloud database is compromised, attackers inherit a static repository of high-value targets that they can attempt to crack offline.
EZPD Password introduces a fundamentally different paradigm. Rather than storing encrypted passwords or ciphertexts in a single cloud vault, EZPD operates as a metadata-driven, multi-cloud fragmented regeneration system.
• No Password Storage: EZPD servers never store actual passwords, neither in plaintext nor in encrypted form.
• Encrypted Metadata Persistence: The server stores only the parameters required for on-demand regeneration such as the password name, character length, and choice of password rule.
• Multi-Cloud Fragmentation: The stored metadata resides in Google Firestore, while the proprietary generation and regeneration software logic executes via Microsoft Azure.
• Decoupled Security (The Separation of Concerns): Even in a hypothetical data breach where an adversary gains access to the metadata store, they cannot regenerate the password without the proprietary regeneration app and two additional input files securely partitioned across independent environments (in Google and Azure).
2. Architectural Comparison: Traditional Vaults vs. EZPD Metadata Architecture
| Architectural Dimension | Traditional Cloud Password Managers | EZPD Password Architecture |
|---|---|---|
| Data Stored on Server | Encrypted password blobs (ciphertexts) of actual credentials. | Encrypted configuration metadata (e.g., password name, character count, rule choices). |
| What an Attacker Steals in a Breach | Actual encrypted passwords that can be targeted with offline brute-force attacks. | Non-executable encrypted metadata attributes (useless without the generation app and split input files). |
| Execution Model | Client downloads blobs, decrypts locally, and autofills a stored secret. | On-demand dynamic regeneration via multi-cloud software logic using stored parameters. |
| Storage & Hosting Topology | Typically, a single unified cloud database instance. | Multi-Cloud Separation: Data in Google Firestore; application logic and software binaries in Microsoft Azure. |
3. Core Mechanics: How On-Demand Regeneration Works
EZPD is a web application designed to generate passwords on demand for first-time use on internet accounts or secure documents, as well as to recreate them identically whenever required.
1. Parameter Definition & Storage: When a user configures a secret, parameters such as the password name, length, and specific rule selections are securely stored as encrypted metadata.
2. On-Demand Computation: When a user needs the password, the web app triggers the regeneration sequence rather than retrieving a static database entry.
3. The Multi-Cloud Fragmented Dependency Chain:
o Component A (Metadata): Stored in Google Firestore.
o Component B (Proprietary App Logic): Hosted and executed via Microsoft Azure.
o Component C & D (Two Additional Input Files): Strategically partitioned and stored across two distinct locations between Google and Azure.
4. The Security Result: A malicious actor who breaches one cloud environment or database only sees fragmented metadata or isolated parameters. They lack the complete dependency chain required to reconstruct the plaintext output.
4. Advanced Features & Business Utility
A. User-Specific Cryptographic Uniqueness
Even if two different users utilize identical parameter metadata (e.g., the same password length and structural rules), no one else can reproduce the exact same password output. Passwords generated within EZPD are strictly user specific.
B. Secure, Frictionless Team Collaboration
For business desktop (or any device) users, teams, or external partners (such as cross-company project teams or family members), sharing passwords traditionally involves risky channels (Slack, encrypted chat, or email).
• With EZPD, group members can independently regenerate the exact same password on demand without ever transmitting the secret across a network to one another.
C. Granular Customization
Users and administrators retain total flexibility, allowing them to customize password rules, lengths, and structural formats to meet internal corporate compliance guidelines or personal security preferences.
5. Threat Modeling & Threat Mitigation
• Scenario: Cloud Database Exfiltration (Google Firestore)
o Outcome: An unauthorized actor accesses the stored metadata (password names, lengths, and rules).
o Mitigation: Because no actual passwords or ciphertexts are stored in the database, and because the proprietary app logic plus two separated input files reside across disparate Azure and Google storage boundaries, the stolen metadata cannot be translated into active credentials.
• Scenario: Interception of Transmission
o Outcome: Traffic between the desktop user and the Azure/Google infrastructure is monitored.
o Mitigation: Secrets are computed on demand during active sessions; static credentials are never permanently stored or broadcast over the wire.
6. Conclusion
EZPD Password redefines B2B desktop credential management by replacing static cloud vulnerability with dynamic, multi-cloud regeneration. By storing only lightweight metadata and fragmenting the cryptographic dependencies across Google and Azure environments, EZPD eliminates the classic "honeypot" risk of traditional password managers while providing seamless on demand access for individuals and collaborative teams.
Contact Information:
ezpd@ezpdpassword.com