CGI authentication scripts: login, session management, and password hashing

Why you must hash passwords, and how

Storing passwords as plaintext means any breach of your password file exposes every user's credentials immediately. Storing a plain MD5 or SHA1 hash is almost as bad, since rainbow tables can reverse common passwords near-instantly. The correct approach is a slow, salted hashing algorithm designed specifically for password storage: bcrypt, Argon2, or scrypt. These add a random salt (preventing rainbow tables) and are deliberately slow to compute (making brute force impractical). Perl has Crypt::Bcrypt on CPAN; Python 3 has the bcrypt package and the built-in hashlib for SHA-256 (though bcrypt is strongly preferred for passwords).

When checking a password at login, you do not decrypt the stored hash. You hash the submitted password with the same algorithm and parameters used when the password was set, and compare the result to the stored hash. A match means the password is correct. This means even you, as the site operator, cannot learn a user's password from the stored hash, which is the correct design.

Session tokens and cookies

After a successful login, generate a session token using a cryptographically secure random number generator. In Perl, use Bytes::Random::Secure or read from /dev/urandom. In Python 3, use secrets.token_hex(). A 32-byte (64 hex character) token is sufficient for most uses. Store the token server-side (in a session file or database row) mapped to the user ID and an expiry time. Send the token to the browser as a cookie with the Secure, HttpOnly, and SameSite=Lax attributes set.

HttpOnly prevents JavaScript from reading the cookie, which reduces the impact of an XSS vulnerability. Secure ensures the cookie is only sent over HTTPS. SameSite=Lax prevents the cookie from being sent in cross-site requests, which is the most practical mitigation for CSRF on standard navigation flows. Set an expiry time and clean up expired sessions server-side, or they accumulate forever.

Protecting pages with a guard script

Each protected page needs to include or call a guard script that runs before the page content is sent. The guard reads the session cookie, queries the session store for that token, checks that the session exists and has not expired, and either proceeds with the page or redirects to the login form. In Perl, requiring a common auth.pl file at the top of each protected script is the typical pattern. In Python, a shared function imported at the top of each handler does the same.

Never output any page content before the session check completes, because HTTP headers (including the redirect) must be sent before any body content. A premature print statement can cause a 'headers already sent' error that prevents the redirect. Print only the Content-Type and any cookie headers before the body, and do the session check before any of that.