Password Police

Password Police, Software Development

1. Framing the Problem

Managing passwords securely is a challenge that affects virtually every person who uses the internet, and the problem compounds as the number of online accounts per person grows. Most people resort to one of three insecure habits: reusing the same password across multiple services, storing passwords in plain-text notes or spreadsheets, or relying on browser-saved passwords with no dedicated encryption layer.

For individuals and small teams who want full control over their credentials without trusting a third-party cloud service, there is a clear gap. Most mainstream password managers like 1Password, Bitwarden, and LastPass are cloud-synced by default, require subscriptions, and involve sending encrypted data to external servers. For privacy-conscious users, this is a non-starter.

Password Police was built to solve this directly. The people affected are individuals, freelancers, and small teams who want a fully local, zero-trust password vault with no subscription and no cloud dependency. The core problem is that no simple, free, local desktop password manager exists with strong encryption, a polished UX, and brute-force protection built in. The risk of inaction is straightforward: passwords stored in spreadsheets or browsers are trivially accessible to anyone with physical or remote access to the machine.

1. Idea Explanation

Password Police is a fully local AES-256 encrypted desktop password manager built on Electron, designed to run on Windows, macOS, and Linux with no internet connection required during normal use.

The core idea is to wrap industry-standard cryptography in a consumer-grade interface and distribute it as a zero-dependency executable. The user defines their own master password on first launch. Everything else, storage, encryption, and brute-force protection, happens entirely on their machine.

The application was built around four principles. First, local-first: all vault data is stored and encrypted locally, nothing is transmitted to any server during normal operation. Second, secure by default: AES-256-GCM authenticated encryption with a fresh random salt and IV on every save, derived from the user's master password via PBKDF2 at 100,000 iterations. Third, zero-dependency distribution: end users receive a single executable with no Node.js, no runtime, no technical setup required. Fourth, brute-force deterrence: five failed login attempts trigger a 24-hour lockout enforced across application restarts, paired with a full-screen animated visual deterrent using the Tung Tung Tung Sahur character.

1. Implementation

Password Police was built in three iterative phases, evolving from a browser prototype to a distributable desktop application.

Phase 1 was the HTML Prototype. The first iteration was a self-contained single HTML file. This allowed rapid prototyping with immediate visual feedback in any browser, validating the core encryption approach and UX flow before committing to an Electron architecture. The prototype included AES-256-GCM encryption via the Web Crypto API, a hardcoded demo password, entry management, auto-lock with countdown, and a dark-themed responsive interface using Space Mono and DM Sans typefaces.

Phase 2 was Branding and UX Refinement. Following prototype validation, eleven discrete UX iterations were applied: renaming to Password Police with a 🚔 icon, integrating the Tung Tung Tung Sahur image as a wrong-password flash, adding dynamic attempt counters and pip indicators, introducing the 24-hour killed screen with a live HH:MM:SS countdown, replacing the hardcoded password with a user-defined one, adding a first-run setup wizard with a password strength meter, and implementing EmailJS-based recovery with a 9-digit code.

Phase 3 was Electron Desktop Packaging. The HTML/CSS/JS codebase was adapted with minimal changes: localStorage was replaced with electron-store, and a contextBridge-based IPC layer was added for security. electron-builder was configured to produce an NSIS installer and portable .exe for Windows, a .dmg for macOS, and an .AppImage for Linux.

The application follows Electron's two-process model with contextIsolation enforced. The Main Process creates the BrowserWindow and handles IPC channels for store-get, store-set, store-delete, and open-external. The Preload Script exposes window.electronStore and window.openExternal to the renderer via contextBridge, meaning the renderer cannot access Node.js or Electron APIs directly. The Renderer Process handles all UI logic, state management, and cryptographic operations, communicating with the main process exclusively through the contextBridge API.

The encryption algorithm is AES-256-GCM for authenticated encryption covering both confidentiality and integrity. Key derivation uses PBKDF2 with SHA-256 at 100,000 iterations. A fresh 16-byte random salt is generated on every save to prevent rainbow table attacks, and a fresh 12-byte random IV ensures a unique ciphertext each time. The master password is never stored in plaintext. Only a separate PBKDF2-derived verification hash is persisted. The decrypted vault exists only in memory during an active session.

1. Challenges

The first challenge was migrating from localStorage to electron-store. The Phase 1 prototype used browser localStorage. When migrating to Electron, localStorage does not persist reliably across app restarts. Replacing it with electron-store required building a full contextBridge-based IPC layer to expose storage operations to the renderer without breaking contextIsolation, which was a non-trivial refactor of the entire persistence model.

The second challenge was an undersized application icon. During packaging, the initial icon was too small for Windows build tooling. The build did not fail clearly, the icon simply rendered incorrectly in Windows Explorer and the Start Menu. The fix required identifying the minimum required resolution of 256x256px, regenerating the icon using Pillow in Python, and rebuilding.

The third challenge was a Windows symbolic link privilege error. electron-builder creates symbolic links during the Windows build process, which requires Developer Mode to be enabled. This is a non-obvious system prerequisite not documented in electron-builder's main setup guide. The build failed silently with a permissions error. Resolution involved enabling Windows Developer Mode and documenting it as a required build prerequisite.

The fourth challenge was client-side recovery verification. Implementing password recovery without a backend required using EmailJS to send a one-time recovery code. Since there is no server, verification logic runs entirely in the browser. A determined attacker with access to the application source could theoretically extract or bypass the check. This is an accepted architectural limitation for a local tool and is addressed directly in Next Steps.

1. Accomplishments

Password Police was successfully delivered from an initial set of informal messaging requirements to a verified, distributable desktop application. All six original requirements were met, with significant scope expansion through eleven development iterations: a first-run setup wizard, email-based password recovery, brute-force lockout with animated visual deterrence, a persistent 24-hour countdown, and a polished one-click build process for cross-platform executables.

Two technical defects were identified and resolved during the build phase. An undersized application icon and a Windows symbolic link privilege error were both diagnosed directly from build output and corrected without impact to the final deliverable or project timeline.

Key things learned include Electron's contextIsolation model and how to architect a secure IPC layer between the main process and renderer, the Web Crypto API in practice covering AES-256-GCM with PBKDF2 and random salt and IV generation, electron-builder configuration for multi-platform targets, and the value of validating encryption logic in a browser prototype before committing to a heavier architecture.

1. Next Steps

The most important improvement is server-side recovery code verification. The current email recovery flow sends a 9-digit code via EmailJS and verifies it entirely client-side, which is the most significant security gap in the current build. The fix is a lightweight backend endpoint using something like a Cloudflare Worker or AWS Lambda function that generates the recovery code server-side, stores a hashed version with a 15-minute expiry, accepts a verification request from the client, compares against the hashed value, and returns a signed token only on match. The code is invalidated immediately after first use and after expiry. This eliminates the ability to reverse-engineer the verification logic from the client bundle.

Clipboard auto-clear is another straightforward improvement. Passwords copied to clipboard currently persist indefinitely and are accessible to any application running on the machine. A 30-second auto-clear timer that overwrites the clipboard after each copy event is a low-complexity, high-impact fix.

A built-in password generator would allow users to create strong credentials at the point of entry creation, removing the common workflow gap where users leave the app to use an external tool. It would be configurable for length, character sets, and exclusion of ambiguous characters.

A password audit feature would scan the vault on demand and surface weak passwords, reused passwords across multiple entries, and passwords appearing in known breach datasets via the HaveIBeenPwned k-anonymity API, which sends only the first 5 characters of a SHA-1 hash so no plaintext ever leaves the machine.

Encrypted export and import would allow vault backup to a portable encrypted file and support importing from common formats like Bitwarden JSON and 1Password CSV to reduce migration friction for new users.

Biometric unlock would offer Touch ID on macOS and Windows Hello as a convenience unlock alternative on supported hardware. The master password would still be required for vault re-encryption and recovery flows, with biometrics serving only as a session unlock shortcut.

System tray integration would allow Password Police to run in the background for faster access without a full relaunch. Currently closing the window terminates the application entirely. Combined with the existing auto-lock timer, running in the tray poses no additional security risk.