How to set up a fortified authentication system
Nine controls for a hardened login: password rules that work, lockouts that cannot be weaponised, MFA that resists bypass, risk scoring, OTP algorithms and TLS.
Most attacks on an internet-facing application start with a credential, not an exploit: a password that was reused, phished or guessed, then used to log in as a real user. A fortified authentication system limits what that stolen password is worth and what the attacker can do with it afterwards.
Nine controls follow, roughly from the cheapest to the ones that need engineering time.
What a fortified authentication system is
It is a login that does not rest on one secret. Identity is verified in layers, for example a password plus a hardware key or a fingerprint, so a single leaked factor does not open the account. Secrets and sessions are protected in transit and at rest with current encryption, and the whole flow is logged, so an attack is visible while it is happening. Built this way, it also covers most of what regulators and standards ask of a login.
1. Define password policies, then enforce them
A password policy only works if the system enforces it. Left to choose, users pick weak passwords, and Secureframe's roundup of password statistics cites a figure of 80 percent of data breaches involving weak passwords.
Set a minimum length and no low maximum; long passphrases are good. Check every new password against lists of breached passwords and reject the matches. Drop the "one number, one symbol" composition rules, which produce Password1! and little else, and point users at a password manager instead.
2. Define account lockout policies
A lockout policy caps how many failed logins an account accepts before it locks, which blunts brute-force guessing.
Pick the threshold from how sensitive the application is and how often people log in, with two cautions. A hard lockout is a denial-of-service tool for anyone who can trigger it against your customers, so prefer progressive delays or a challenge over a lock. And a bot running credential stuffing tries each account once, so count failures per source IP and device as well as per account.
3. Turn on multi-factor authentication
Multi-factor authentication asks for something beyond the password: a code from an authenticator app, a push approval, a hardware key, or at the weak end a text message. Even with the password stolen, the attacker still needs the second factor.
Not all factors hold. SMS codes can be intercepted or phished, so read the bypass techniques attackers use and choose a factor that survives them. Hardware keys and passkeys do, because the response is bound to the site's origin and cannot be replayed elsewhere.
Ask for the second factor when a login looks risky rather than on every login, and most customers will rarely see it.
4. Know who attacks you and how
Work out which threat actors target a company like yours and how they operate.
Who are they, what do they want, and what does their traffic look like from your side?
Their aims are stealing data, hijacking accounts or disrupting operations, and the methods repeat: phishing mail that collects staff credentials, credential stuffing against the customer login, brute force against admin panels. Once you know which of these you see, you know which of the other controls to do first.
5. Use machine learning to score logins
Rules catch what you have already seen. Machine learning catches what does not fit.
Feed it the data you already collect on each login (device, network, time, behaviour) and let it flag the anomalies: a known account from a new device in a new country, a burst of logins that share one fingerprint, a session that moves faster than a person. The output is a risk score, and the score decides whether the login passes, gets a challenge, or is blocked.
6. Biometric authentication
Biometrics verify a person by a physical trait: fingerprint, face, iris. They are fast and need nothing to remember, which is why phones default to them.
Their weakness is that a fingerprint cannot be changed once leaked. Keep the matching on the user's device, as phone platforms do, and never store raw biometric templates on your servers. Used that way, a biometric is a strong "something you are" factor alongside the password.
7. Pick the one-time password algorithm that fits
If you issue one-time codes, decide how they are generated.
OATH-HOTP generates codes from a counter and is simple to implement; its time-based variant, TOTP, is what most authenticator apps use. RSA-based token schemes exist too and are usually tied to one vendor's hardware.
Choose on how you will handle the hard cases rather than on which sounds more secure: counter drift for HOTP, clock skew for TOTP, and seed storage for both. Whichever you pick, the seed is a secret; protect it like the password database.
8. Use the right cipher suite for each use case
Not every cipher suite is equal, and the right one depends on what you are protecting: a connection, a stored secret, or a message.
For connections, run TLS 1.3, or TLS 1.2 with only authenticated encryption suites such as AES-GCM, and turn off anything that still uses SHA-1 or CBC mode. For email, PGP and S/MIME are the encryption standards. For passwords, do not encrypt at all: store a slow, salted hash.
9. Use a certificate authority for strong identities
Where the identity is a machine or a member of staff, a certificate beats a password. A certificate authority issues each user or service a unique certificate and the system identifies them by it, so the login is bound to a private key that cannot be phished or stuffed. Use it for admin access, service-to-service calls and VPN. It does not stop fake customer signups; that is a job for risk scoring at the signup form.
Where to start
Do the cheap things first: enforce the password policy, count lockout failures per source, and turn on a second factor for staff and admin accounts this week.
Then put risk scoring on the customer login, so the second factor is asked for only when the device, network or behaviour does not fit the account.
To see how Sensfrx scores each login and turns the score into allow, review or block, read about account takeover protection.