Our target : PrivLock

We are God’s people. We believe in God. We believe in the Constitution. But we don’t believe in government and big corporations. That’s why PrivLock was founded..

High-Level Summary of the Entire Design

The system is a privacy-focused, secure login manager with three main subsystems: Login/Auth, Signup, and User Admin. It uses HAProxy as a reverse proxy, C/Go backends for logic, and Redis for storage. Key features include:

• Login/Auth: Protects “/protect/1-9/” areas with username+SHA256(password) from clients, enhanced by salted Argon2id in Redis. Session tokens (cookies) manage access, with rate limiting (10 tries/3600s) and HAProxy DoS protection.
• Signup: Self-service at “/signup” with IP limits (1 signup/3600s), atomic username locking, and a self-hosted CAPTCHA. New users get level 0 and a 30-day TTL.
• User Admin: Admin GUI at “/useradmin/” (Go-based) with IP whitelisting, strict rate limits, and audit logging. Admins (select 10) manage users (approve, delete, reset passwords) separately from self-signed users (levels 1-9).
• Privacy: No email/phone recovery; lost passwords mean re-signup (users) or admin reset (admins). Password changes are self-service for logged-in users/admins.
• Security: Self-hosted CAPTCHA, atomic operations, and Redis fallbacks (deny logins if down) ensure robustness.

Breakdown into Pieces (Jobs) with Targets/Summaries

Piece 1: Login/Auth System

• Components: HAProxy, .c backend, Redis (select 0, 1).
• Target: Securely authenticate users and grant access to “/protect/1-9/” based on levels (0-9), with session management and rate limiting.
• Summary: HAProxy routes “/protect/*” requests, redirecting unauthenticated users to “/login”. The client submits username:sha256(passwd), and the .c backend verifies it against user:username:hash (salted Argon2id) in Redis (select 0). Successful logins get a session token (cookie, stored in Redis), and HAProxy enforces level-based access (e.g., level 3 sees “/protect/1-3/”). Rate limits (10 tries/3600s per user/IP, select 1) use HAProxy’s silent-drop for DoS protection. Redis downtime triggers a deny-all fallback.

Piece 2: Signup System

• Components: HAProxy, .c2 backend, Redis (select 0, 5).
• Target: Allow self-signup with privacy and bot protection, assigning level 0 and a 30-day TTL to new users.
• Summary: HAProxy listens on “/signup”, forwarding to .c2. The backend checks signup:ip (select 5, 1 signup/3600s), enforces username rules (a-zA-Z start, 8+ chars), and uses SETNX for atomic user:username creation in Redis (select 0). A self-hosted image CAPTCHA (DIY, Redis-backed) deters bots. New users get level: 0 and TTL 30 days; expired users are fully deleted, freeing usernames.

Piece 3: User Admin System

• Components: HAProxy, .go backend, Redis (select 10, 11, 12, 13, 14).
• Target: Provide a secure admin GUI for managing users (approve, delete, reset passwords) with audit trails and privilege separation.
• Summary: HAProxy routes “/useradmin/*” to .go, protected by admin auth (select 10, admin:username:hash). IP whitelisting (select 11) allows 10 tries/3600s (select 12), non-whitelisted get 1 try (select 13), with a self-hosted CAPTCHA. Admins (levels 8-9) approve users (set level 1-9, remove TTL), delete (mark status: deleted), or reset passwords (temp pass). Audit logs (select 14) track actions. Superadmins (level 9) handle lockouts via whitelist updates.

Piece 4: Password Change System

• Components: HAProxy, .c (users), .go (admins), Redis (select 0, 10).
• Target: Enable logged-in users and admins to change their passwords securely.
• Summary: “/change_pass” (via .c) and “/admin/change_pass” (via .go) allow password updates. Clients submit current sha256(passwd) and new sha256(new_passwd); backends verify sessions, re-hash the new password (salted Argon2id), and update user:username:hash (select 0) or admin:username:hash (select 10). No recovery—lost passwords mean re-signup (users) or superadmin reset (admins).

Piece 5: CAPTCHA System

• Components: HAProxy, .c/.c2/.go backends, Redis (flexible select, e.g., 6).
• Target: Prevent bot abuse across login, signup, and admin systems with a privacy-respecting, self-hosted solution.
• Summary: A DIY image CAPTCHA (e.g., distorted text) is served at “/captcha” (login), “/signup/captcha”, and “/admin/captcha”. Generated by backends (.c, .c2, .go), answers are stored in Redis (e.g., captcha:session_id -> answer, TTL 5 min). HAProxy redirects to CAPTCHA on rate limit triggers, ensuring bot resistance without external dependencies.

Piece 6: Redis Structure and Fallbacks

• Components: Redis (all selects: 0, 1, 5, 6, 10, 11, 12, 13, 14).
• Target: Organize data efficiently and handle Redis downtime gracefully.
• Summary: Redis namespaces:
  • 0: Users (user:username -> {hash, salt, level, status})
  • 1: Login attempts (attempts:user:ip)
  • 5: Signup tracking (signup:ip)
  • 6: CAPTCHA (e.g., captcha:session_id)
  • 10: Admins (admin:username -> {hash, salt, level})
  • 11: Whitelist (whitelist:ip)
  • 12/13: Admin attempts (attempts:admin:ip)
  • 14: Audit logs (audit:timestamp) Fallback: deny logins if Redis is down, log to file for debugging.