Secure Custom Login Pages

Building a login page, whether manually or with the help of AI, can be dangerous if done carelessly.

Small mistakes in authentication, validation, or data handling can lead to major security breaches.

These are some things to take into consideration:

What is XSS?

XSS happens when a website includes untrusted input in a page without properly sanitizing it.

Sanitizing (or escaping) means converting special characters into safe text so the browser treats them as data, not code.

If malicious code runs on a login page, it can:

• Read what users type into username/password fields
• Capture credentials before they’re sent to the server

If session cookies or tokens are accessible:

• The attacker can steal them
• Reuse them to log in as the victim without knowing the password

Malicious scripts can:

• Change page content
• Hide warnings or security messages
• Show fake alerts or forms

he attacker can:

• Automatically send users to fake login pages
• Redirect them to malware-hosting sites

What’s Session Fixation?

Session fixation is a type of security attack where an attacker tries to take over a valid user session by tricking the user into using a session ID that the attacker knows.

Websites use sessions to remember users because HTTP, the protocol behind the web, is stateless, meaning the server treats each request as independent.

To track users, websites create a session for each visitor and assign it a session ID, which is a unique, random string.

session_id=XYZ123

This session ID acts like a temporary digital identity. When you log in, your browser stores this session ID, usually in a cookie, and sends it back to the server with every request. The server uses it to recognize you, keep track of your login status, and manage your personal data like preferences or shopping cart items.

Normally, session IDs are randomly generated when a user starts a session, and a new session ID is ideally created after the user logs in, to ensure security.

Session fixation attacks take advantage of poor session management. In this type of attack, an attacker either generates a valid session ID or obtains one from the target website. Then, they trick the victim into using that session ID. This can happen through a specially crafted link, a malicious website, or sometimes by exploiting websites that accept session IDs through URLs.

https://example.com/login?session_id=ATTACKER123

The victim unknowingly uses the attacker’s session ID when logging in. If the website doesn’t generate a new session ID upon login, the session that was initially controlled by the attacker becomes authenticated, giving the attacker full access to the victim’s account without needing their password.

This vulnerability exists mainly because some websites allow session IDs to be reused across login or accept session IDs from untrusted sources.

It can be prevented by regenerating session IDs after login, which ensures that any pre-existing session IDs become useless

Always Make Login Responses Indistinguishable

A secure login system should never reveal whether a username exists or not.

Differences in error messages, response time, or backend behavior can allow attackers to enumerate valid accounts through trial and measurement.

To prevent this, login responses must be indistinguishable for both valid and invalid usernames. This can be achieved by always performing password verification, using a real hash for existing users and a fake hash for non-existent ones, or by otherwise normalizing execution time and behavior.

The goal is simple: ensure every failed login attempt looks and feels the same, eliminating subtle leaks that can be exploited.

Add a Session Time Out

Login pages should add a session timeout because it protects users and systems from unauthorized access and misuse.

A session timeout automatically logs them out after inactivity.

Here are the main reasons:

• This prevents others from accessing sensitive data if the device is left unattended.
• Attackers can hijack active sessions and a session timeout limits how long a stolen session remains usable.
• Inactive sessions consume server resources. Timing them out helps free memory and processing capacity.

Single Device Login

When you log into your account on a new device, the system checks when the old device tries to do anything (load a page, send a request), checks its session, sees it’s no longer valid, and logs the user out.

To log out the user from the old device immediately without any user action, the app needs some kind of background check.

That’s usually done with JavaScript polling, where the browser quietly asks the server every few seconds, “Is my session still valid?”

The trade-off is that polling:

• Adds extra network requests
• Needs careful timing (too frequent = wasteful, too slow = delayed logout)

Because of that, many apps accept “near real-time” logout (on the next click), while more security-sensitive apps use polling or real-time connections to make it feel instant.

Questions:

Rate Limiting

Rate Limiting limits how many authentication attempts a user, account, or IP address can make before being slowed down or temporarily blocked.

IP-Based Rate Limiting

You track failed attempts per IP and block the IP when a threshold is exceeded.

5 failures from 203.0.113.42 → block IP for 15 minutes

A major and often overlooked problem with strict IP-based rate limiting is that IP addresses are frequently shared by many legitimate users.

Corporate offices, mobile carriers, coffee shops,can place hundreds of users behind a single public IP address.

In these environments, a single malicious actor can trigger a lockout that denies access to everyone sharing that IP.

At the same time, determined attackers can easily evade IP blocks by rotating through proxies, Tor, VPNs, or large cloud IP pools, rendering hard IP locks ineffective.

Even worse, attackers can weaponize IP-based locking by intentionally submitting failed login attempts to deliberately lock out real users, turning the protection mechanism itself into a denial-of-service vector.

Account – Based Rate Limiting

Account-based rate limiting offers strong protection against brute-force attacks by directly limiting repeated failed login attempts on a specific account, making it effective even when attackers rotate IP addresses.

By tying limits to the account itself, it helps safeguard high-value users and prevents unlimited guessing of a single password.

5 failures from TinyDancer → block IP for 15 minutes

However, this approach also has drawbacks: if implemented poorly, it can enable username enumeration or allow attackers to intentionally lock users out by repeatedly failing logins on their behalf. Account-based limits can also frustrate legitimate users who mistype their credentials multiple times, especially if lockout periods are long or inflexible

Progressive Rate Limiting

Progressive rate limiting is a way websites or apps gradually restrict how often someone can make requests, instead of blocking them all at once.

Rather than saying “you’re blocked immediately”, the system:

1. Allows normal use
2. Slows you down if behavior looks suspicious
3. Adds stronger limits if the suspicious behavior continues
4. Block if behavior gets really bad

Normal use   Suspicious      Repeated abuse
██████████ → ██████░░░░ → ███░░░░░░░ → BLOCK
Fast            Slower          Very slow

Captchas

CAPTCHAs are short tests used on websites to tell humans and computers (bots) apart.

They help prevent:

• Spam comments or fake accounts
• Automated logins or hacking attempts
• Bots buying tickets or items unfairly
• Abuse of online forms

Math CAPTCHAs

Math CAPTCHAs are best understood as speed bumps, not real security controls.

A speed bump doesn’t stop a determined driver, it just slows casual traffic and discourages reckless behavior.

Math CAPTCHAs work the same way. They can block the simplest automated scripts that blindly POST login forms, but they do nothing to stop modern attackers.

Any bot capable of parsing HTML can read a math question, solve it instantly, and submit the correct answer faster than a human. From a security standpoint, arithmetic is trivial computation.