While SSH 2FA is commonly covered, application-level MFA — protecting your actual web applications and admin panels, not just server access — is equally important and often overlooked.
Why Application-Level MFA Matters Separately from SSH MFA
SSH MFA (see How to Enable Two-Factor Authentication (2FA) for SSH on a Linux VPS) protects server access; it does nothing to protect your actual web application's login — these are genuinely separate authentication surfaces, both deserving MFA protection independently.
TOTP-Based MFA (Most Common Approach)
Time-based One-Time Password (the same mechanism used by apps like Google Authenticator/Authy) is the most widely-supported and implementable MFA approach for web applications — most modern web frameworks have libraries supporting TOTP generation/verification.
Implementing TOTP in a Node.js Application
npm install speakeasy qrcodeconst speakeasy = require('speakeasy');
const secret = speakeasy.generateSecret({ name: "MyApp" });
// Store secret.base32 securely associated with the user
// Display secret.otpauth_url as a QR code for the user to scanVerifying a TOTP Code
const verified = speakeasy.totp.verify({
secret: user.totpSecret,
encoding: 'base32',
token: userSubmittedCode,
});Implementing TOTP in Python (Django/Flask)
pip install pyotpimport pyotp
secret = pyotp.random_base32()
totp = pyotp.TOTP(secret)
totp.verify(user_submitted_code)Storing the TOTP Secret Securely
The TOTP secret itself is sensitive — store it encrypted, similar to how you'd handle other sensitive credentials (see Data Encryption at Rest: What It Means and How to Implement It), not in plain text in your database.
Providing Backup/Recovery Codes
Always generate and provide one-time backup codes when a user enables MFA — covers the scenario where they lose access to their authenticator device; store these hashed (similar to passwords), not in plain text.
Making MFA Enforceable, Not Just Optional
Consider whether MFA should be required (particularly for administrative accounts) rather than purely opt-in — optional MFA protects only the subset of users who proactively enable it, leaving others exposed.
Using WebAuthn/Passkeys as a Stronger Alternative
Beyond TOTP, WebAuthn (supporting hardware security keys and platform authenticators like Face ID/fingerprint) offers even stronger phishing-resistant authentication — more complex to implement than TOTP, but worth considering for genuinely high-security applications.
MFA for Third-Party Service Access
Beyond your own application, ensure MFA is enabled on every third-party service you depend on with administrative access implications (cloud provider consoles, domain registrar, payment processor dashboards) — these are frequently overlooked but genuinely high-value targets for attackers.
Testing Your MFA Implementation
Verify the actual enforcement is correct — test that bypassing MFA genuinely isn't possible through any code path, since a partial/inconsistent implementation provides false confidence.
Common Errors
MFA implemented but bypassable through a password reset flow — a common oversight; ensure password reset and account recovery flows don't inadvertently provide an MFA bypass path for an attacker who's compromised just the email account.
Continue Reading
- How to Enable Two-Factor Authentication (2FA) for SSH on a Linux VPS
- How to Implement Role-Based Access Control for Compliance
- Understanding and Mitigating the OWASP Top 10 Vulnerabilities
Browse more articles in Advanced Security & Compliance.
