Piece 2: Signup System(Login 3)

Link : github source code

Components

• HAProxy: Acts as the reverse proxy, listening on “/signup” and forwarding requests to the .c2 backend.
• .c2 Backend: A separate C-based backend (distinct from the .c login backend) handling signup logic.
• Redis: Stores signup tracking (select 5) and user data (select 0).

Target

• Allow users to self-sign up for an account with privacy as the highest priority, assigning them level 0 and a 30-day TTL, while preventing bot abuse and ensuring unique usernames.

Requirements (Your Inputs)

1. Endpoint: HAProxy listens on “/signup”, accessible to anyone for self-signup.
2. Backend: Requests are redirected to .c2 (you labeled it .c2 to distinguish it from the login .c backend).
3. IP Limiting: Track user/ip in Redis “select 5” with a TTL of 3600s. If an IP has successfully signed up within 3600s, redirect to an HTML page saying “Your IP has already registered. Multi-register is not allowed.”
4. Username Rules: Allow signup if the username:
   • Starts with a-zA-Z.
   • Contains only a-zA-Z0-9.
   • Is more than 8 characters.
   • Doesn’t already exist.
   • Return a generic “signup failed” error for any failure (no specific reasons like “username exists”).
5. New User Settings: Set TTL to 30 days and level to 0 (no extra privileges).
6. Storage: Save new users to “select 0” (you confirmed this as the user database).
7. Privacy: No email or phone verification—users re-sign up if they lose passwords.
8. Atomicity: Lock username insertion to prevent simultaneous duplicates (you agreed it’s unlikely but worth doing).
9. IP Blocking Logic: 1 signup per IP in 3600s isn’t strict—users should wait if they need another account.
10. CAPTCHA: No Google CAPTCHA; add a self-hosted CAPTCHA replacement for bot protection (you requested this for signup, login, and admin).
11. TTL Expiry: If a new user’s TTL (30 days) expires, delete the account completely, allowing username reuse.
12. Username as Key: Use username as the key in Redis (e.g., for GET/SET or HGET/HSET).

Conceptual Solutions (My Suggestions Integrated with Your Decisions)

1. Flow:

The Sneaky Slash

How a Double Forward Slash Bypassed My HAProxy Security Rules

Introduction

Yesterday, I discovered a concerning security hole in my HAProxy configuration that made me question how secure my admin area really was. I’m sharing this finding and solution to help others who might have the same vulnerability without realizing it.

The Discovery

I had set up HAProxy to protect my website’s admin panel using a seemingly solid approach:

C code for CAPTCHA (Login 3)

Building a Self-Hosted CAPTCHA System with HAProxy

After preparing the HAProxy server and the authentication Lua verification script, I needed to develop a PNG generator and user authentication mechanism to complete my self-hosted CAPTCHA server. I decided to use C for the core functionality due to its performance and control over system resources..

The Authentication Flow

My authentication logic follows these key steps:

Evolving Web Authentication(login 1)

From Simple Cookies to Secure Sessions

In the early days of web applications, servers used a straightforward approach to identify returning users. When you logged in, the server would issue your browser a cookie - a small piece of data that identified you as an authenticated user.

During subsequent visits, your browser automatically submits this cookie with each request. The server would perform a simple check: “Does this request include a cookie named ‘your_name_session’?” If yes, access granted. This basic system worked well initially.

Finding a Login Protection Solution

For any website, robust login protection is crucial. Existing solutions often fall short of my requirements:

1. Security
2. Dynamic capability
3. Resistance to brute force attacks

I analyzed many options and initially considered Aerospike and ScyllaDB as ideal solutions. However, I abandoned these ideas because they proved too difficult to compile from source on standard Linux systems. I attempted builds on both Debian and Alpine with no success.