Loginguards

• 

  Login Guards

About the Project LoginGuards started as an idea from Engineers Mina and Kirolos. They came to me with a simple but powerful concern: “Why do companies still allow users to register with passwords that were already exposed in massive breaches?” That question became the seed of this project. They believed there should be a practical way for developers and businesses to check whether a password had already appeared in known breach datasets — before allowing it into their systems. From there, my role was to turn that vision into a complete, production-grade product. I created the full Product Requirements Document (PRD), designed the architecture, and built the entire system — frontend, backend, database, infrastructure — and deployed it on Azure. LoginGuards became the technical realization of their idea. The Inspiration The core inspiration was simple: Credential stuffing attacks continue to succeed not because systems are weak — but because users reuse compromised passwords. Traditional validation focuses on password strength: But strength alone does not equal safety. If a password already exists in breach datasets, then: LoginGuards was built to measure exposure, not just complexity. My Role in the Project Mina and Kirolos brought the initial concept. I handled: Writing the full PRD Designing system architecture Planning authentication flows Designing the database structure Building the backend API Building the frontend dashboard Designing and implementing the CLI Deploying and configuring infrastructure on Azure VM Hardening the system for production Integrating Stripe billing Implementing Microsoft Entra CIAM authentication In short, I transformed the idea into a working, scalable SaaS platform. How It Was Built Infrastructure Azure VM deployment PostgreSQL database Redis for caching Secure networking and firewall configuration Reverse proxy and TLS configuration Cloudflare + Azure routing layers Backend FastAPI (Python) High-performance breach dataset lookup (~2.6B records) Support for: Plaintext password checks SHA-1 SHA-512-30 Dual authentication model: API Key JWT (Microsoft Entra CIAM) Strict issuer validation for security integrity Frontend Next.js Admin dashboard Usage monitoring Stripe billing integration CLI Built in Go Cross-platform Designed for CI/CD integration Secure API-key-based communication Challenges We Faced

1. Handling Billions of Records Working with ~2.6 billion compromised credentials required: Careful indexing Memory optimization Query performance tuning Normalization of hash formats At this scale, even small inefficiencies become architectural problems.
2. Authentication Complexity Using Microsoft Entra CIAM with a custom domain while preserving the default issuer required precision. One small misconfiguration in the OIDC path caused security warnings, and resolving it required understanding the entire trust chain.
3. Security Hardening Since this is a security product, the system itself had to be hardened: Strict JWT validation No sensitive logging API key protection Proper TLS configuration Layered infrastructure routing Security tools must be built to a higher standard. What I Learned This project reinforced several key lessons: Ideas are powerful — but execution determines impact. Security architecture requires precision at every layer. Scale changes design decisions. Developer experience matters as much as security. Most importantly, collaboration matters. Mina and Kirolos had the initial vision. I translated that vision into architecture, code, and a deployed system. Why LoginGuards Matters Credential stuffing remains one of the most common attack vectors globally. LoginGuards enables businesses to reject compromised passwords proactively — reducing risk before it becomes an incident. Instead of reacting to breaches, it enables prevention

Built With

• aks
• azure
• cloudflared
• javascript
• next.js
• postgresql
• python
• typescript
• vm