zCloudPass

Overview

zCloudPass started as a response to a simple observation: most password managers either ask users to trust the server or quietly compromise on usability. The goal here was to avoid both trade-offs.

This project is a cross-platform, zero-knowledge password manager built with a strong bias towards client-side control. Every sensitive operation, from key derivation to encryption, happens locally. The server acts as a blind storage layer.

From a portfolio perspective, this project reflects an attempt to combine applied cryptography, distributed system design, and real-world product thinking into a single cohesive system. It is not just a UI project or a backend service. It is an end-to-end security-focused application.

---

Problem

While working with existing password managers and encrypted tools, a few patterns became obvious:

• Many “secure” apps still rely on implicit server trust
• Cross-device sync often introduces attack surface or complexity
• Browser integration is either clunky or intrusive
• Offline usage is rarely handled properly
• Security features often come at the cost of usability

There is also a deeper issue. Most users do not understand where encryption actually happens. If the server participates, the model is already weakened.

The problem this project addresses is:

Can a password manager be secure by design, not by policy, while still being usable across devices and platforms?

---

Solution

The approach taken in zCloudPass is strict:

The server should never be capable of reading user data. Not even theoretically.

Architecture Decisions

Instead of building a traditional full-stack app, the system is split with very clear responsibilities:

Client (Primary System)

• Performs all encryption and decryption
• Owns key derivation
• Manages vault structure and updates

Server (Dumb Storage Layer)

• Stores a single encrypted_vault blob per user
• Handles authentication and session tokens
• Never processes plaintext data

This separation enforces the zero-knowledge model at an architectural level rather than relying on discipline.

---

Implementation Breakdown

Desktop App

Built using React + Vite + Tailwind + Tauri

• Tauri was chosen over Electron to reduce footprint and improve performance
• Rust layer acts as a thin native wrapper
• UI focuses on fast vault access and minimal friction

A key challenge here was balancing native feel vs web flexibility, especially when handling secure local operations.

---

Browser Extension

The extension was designed to solve a very practical problem:

A password manager that cannot integrate with login flows is effectively incomplete.

Features implemented:

• Automatic form detection
• Save prompts on login
• Autofill with minimal interaction
• Vault browsing inside popup

One interesting edge case was handling inconsistent form structures across websites. The solution leans on heuristic detection rather than rigid selectors.

---

Backend

Built with Rust (axum + sqlx + PostgreSQL)

This is intentionally minimal.

• Issues session tokens
• Stores encrypted vault blobs
• Provides basic auth endpoints

One important note:

The current authentication flow is deliberately incomplete for production. It does not yet implement strong verification mechanisms like SRP. This was a conscious decision to keep the focus on client-side security first.

---

Security Model

• PBKDF2 (100k iterations) for key derivation
• AES-256-GCM for encryption
• No plaintext secrets leave the client
• Vault is always transmitted as an opaque blob

Additional planned layers:

• 2FA integration
• Biometric unlock (platform-native)
• Breach detection APIs
• Password strength analytics

---

Developer Experience Decisions

This project also doubles as a development scaffold.

• Frontend and backend are decoupled
• API is simple and inspectable
• Extension works without a build step
• Local development is straightforward

The idea was to make it easy to experiment with:

• Different encryption strategies
• Alternative auth flows
• Sync mechanisms

---

Developer Notes

What Went Well

• Clear separation between client and server reduced complexity later
• Tauri significantly improved performance compared to Electron-based alternatives
• Keeping encryption logic centralised avoided duplication across platforms

---

Challenges

• Designing a system without a master password while still maintaining security assumptions is non-trivial
• Browser autofill is inconsistent across sites and requires constant tuning
• Syncing encrypted blobs introduces versioning and merge concerns

---

Trade-offs

• Simplicity of backend vs production readiness
• PBKDF2 chosen for compatibility, though Argon2 would be stronger
• LocalStorage for session tokens is convenient but not ideal for high-security environments

---

Deployment

• Frontend deployed via Vercel
• Backend expected to run separately with PostgreSQL
• Native builds handled via Tauri per platform

---

Contribution

This project is intentionally open-ended.

If someone contributes, the expectation is not just code, but thinking about security implications first. Small changes in this system can have large consequences.

---

Current State

• Functional as a development prototype
• Not production-ready
• Core architecture is stable
• Security model is in place but not fully hardened

---

Closing Note

This project is less about building “another password manager” and more about exploring:

• What zero-knowledge actually means in practice
• How far client-side responsibility can be pushed
• Where usability starts to conflict with security

It is a work in progress, but the foundation is deliberate and opinionated.