Multi-factor authentication is missing

As long as an account is protected by a password alone, its security is only as strong as a secret your user may also have used elsewhere. That is the heart of the problem: you are securing your application with something you have no control over. A second factor changes that picture, and choosing the right form is the difference between a real barrier and an apparent one.

What is multi-factor authentication?

Multi-factor authentication (MFA) means a user proves their identity with evidence from more than one category: something they know (a password), something they have (a key or phone) and something they are (a fingerprint or face scan). What matters is the combination of categories, not the number of steps; two passwords in succession is not MFA.

The underlying idea is that it is plausible for one piece of evidence to fall into the wrong hands, and unlikely for both to do so at once. A password leaks through a breach at another service, gets guessed, or is handed over on a fake login page. A physical key or a linked phone does not automatically follow.

It is the bank vault that needs two keys at once: the customer’s and the bank employee’s. Not because either key is bad, but because the risk of both ending up with the same person is substantially smaller.

Which forms offer real protection?

Not every second factor is equally strong, and the difference lies mainly in resistance to phishing.

Vulnerable:

// One factor, and access is settled
app.post('/login', async (req, res) => {
  const user = await users.findByEmail(req.body.email);
  if (!user || !await argon2.verify(user.hash, req.body.password)) {
    return res.status(401).send('Invalid credentials');
  }

  req.session.userId = user.id;
  res.send('Welcome');            // full access
});

Whoever has the password is in. And that password comes, in practice, from one of three sources: a breach at another service where the user reused it, a successful guess, or a phishing page where they entered it themselves.

Safe:

app.post('/login', async (req, res) => {
  const user = await users.findByEmail(req.body.email);
  if (!user || !await argon2.verify(user.hash, req.body.password)) {
    return res.status(401).send('Invalid credentials');
  }

  // No session yet: only a short-lived, restricted intermediate state
  req.session.secondFactorFor = user.id;
  req.session.expiresAt = Date.now() + 5 * 60 * 1000;
  res.redirect('/login/verify');
});

app.post('/login/verify', async (req, res) => {
  const id = req.session.secondFactorFor;
  if (!id || Date.now() > req.session.expiresAt) {
    return res.status(401).send('Verification expired');
  }
  if (!await verificationValid(id, req.body)) {          // passkey or TOTP
    await recordFailure(id);
    return res.status(401).send('Verification failed');
  }

  req.session.regenerate(() => {
    req.session.userId = id;                            // only now a real session
    res.redirect('/');
  });
});

The crucial detail is that after the password there is not yet a usable session. The intermediate state only grants the right to complete verification, is short-lived, and gives no access to any data. A common mistake is to create the session immediately and enforce the second factor only in the interface, which can then be bypassed with a direct request.

For the verification itself, strength varies widely. Passkeys and hardware keys following the WebAuthn standard are phishing-resistant because the key is bound to your domain. An authenticator app with one-time codes is a good middle ground. SMS is the weakest form, because the code can easily be requested on a fake page and relayed immediately.

What is the impact of missing MFA?

The severity is medium to high, depending on what sits behind the application and whether administrator access is involved. What sets this finding apart is that the attack need not begin in your application at all.

In credential stuffing, combinations from earlier breaches are tried automatically. Because password reuse is widespread, that reliably yields a percentage of successful logins, without anything being wrong with your security. In phishing, the user hands over their password voluntarily on a fake page. In both cases there is no vulnerability in your code; there is simply nothing stopping the stolen password.

The consequences follow accordingly. For an ordinary user account it means access to personal data and the ability to act on that person’s behalf. For an administrator account it means the whole system. And because the attacker arrives with valid credentials, their activity looks like normal use in the logs, which makes detection considerably harder.

How do you detect missing MFA?

The first observation is simple: does the application offer a second factor, and if so, which forms? Then begins the investigation that really says something.

A tester checks whether the second factor is enforced on the server by skipping the verification screen and calling a protected route directly with the session created after the password step. If that works, the MFA is cosmetic. They also check whether the intermediate state is short-lived, whether the number of verification attempts is limited, and whether one-time codes really can be used only once. The detours get attention too: the password reset function, recovery codes, and API endpoints or older protocols that ask only for a password. That last one is a classic finding: an application with proper MFA in the web interface whose API accepts the same credentials without a second factor. AssistSec tests those routes explicitly, because the weakest entrance determines how strong authentication really is.

How do you prevent missing MFA?

• Offer multi-factor authentication for all accounts and make it mandatory for administrators and sensitive roles.
• Prefer passkeys or hardware keys following WebAuthn; those resist phishing.
• Use an authenticator app with time-based codes as an alternative, and SMS only as a last resort.
• Create a full session only after the second factor has been verified, not before.
• Enforce verification on the server on every route, including APIs and older protocols.
• Limit the number of verification attempts and invalidate one-time codes immediately after use.
• Secure the recovery route as strongly as the login route; otherwise you only move the problem.
• Use number matching with push notifications to counter MFA fatigue.
• Ask for the second factor again before sensitive actions and on an unknown device or unusual location.