Learn 2FA Authentication - History, Background & Why You Need It

#Introduction

Authentication is the gateway to every application. For decades that gateway was guarded by a single key: the password. Episode 1 opens the series by exploring why a single key is not enough, how the industry evolved from passwords to SMS-based OTPs, then to authenticator apps (TOTP), and finally to WebAuthn passkeys.

You will also get to know the standards that support it all — RFC 4226 for HOTP and RFC 6238 for TOTP — along with two security frameworks that are often used as references: NIST SP 800-63B and the OWASP Authentication Cheat Sheet. By the end of the episode, you'll understand why 2FA is not just a feature, but a requirement for attack mitigation and enterprise compliance.

#The Evolution of Authentication: from Password to Passkey

#Password Only: A Weak Starting Point

A pure password is a single factor: something you know. The problem is that knowledge can be stolen. The three most common attacks exploit this weakness:

• Credential stuffing: lists of emails and passwords from other database breaches are automatically replayed against your application. Because most users reuse passwords, one breach on one site spreads to every site.
• Brute-force: weak passwords are guessed automatically using dictionaries of common words.
• Phishing: fake login pages steal the passwords users type in directly.

These three attacks run automatically and at scale. Even a long password doesn't help if the user enters it on a fake site.

#SMS OTP: A Fragile Improvement

The industry's first step was OTPs sent by SMS. At first glance this adds a possession factor — the code arrives at a number only the user owns. But SMS has weaknesses: SIM swapping, where an attacker hijacks the victim's phone number, and codes that can be intercepted over weak telecom networks. NIST explicitly downgrades SMS to restricted status for high-risk authentication.

#Authenticator Apps (TOTP) and WebAuthn Passkeys

Authenticator apps solve the SMS problem: the code is computed on the user's device from a shared secret, doesn't depend on a phone carrier, and works offline. This is the TOTP used by Google Authenticator — the main focus of this series. At the very top level, WebAuthn passkeys remove the shared secret entirely with asymmetric cryptography and full phishing resistance. Episode 17 will dissect WebAuthn in depth.

#The Standards Behind 2FA

#RFC 4226 (HOTP) and RFC 6238 (TOTP)

All modern authenticator apps stand on two publicly readable standard documents:

curl -s https://www.rfc-editor.org/rfc/rfc4226.txt -o hotp.txt
curl -s https://www.rfc-editor.org/rfc/rfc6238.txt -o totp.txt
wc -l hotp.txt totp.txt

RFC 4226 (2005) defines HOTP, a counter-based one-time password that increments every time the code is used. RFC 6238 (2008) defines TOTP, a variant of HOTP that replaces the counter with time — the UNIX epoch divided by a 30-second period. Both use HMAC-SHA1 and produce 6 digits, and rfc-editor.org/rfc/rfc6238.txt is a valid source for verification.

#NIST SP 800-63B and the OWASP Authentication Cheat Sheet

NIST SP 800-63B classifies assurance levels from AAL1 to AAL3. AAL2 requires two factors with a software OTP (TOTP) or hardware, while AAL3 demands cryptography-based factors such as hardware keys. The OWASP Authentication Cheat Sheet summarizes implementation practices — server-side verification, timing-safe comparison, and credential rotation — that you will follow from episode 13 to 16.

#Why 2FA: Adding the Possession Factor

This concept is the short answer to the most fundamental question of this series: why isn't a password alone enough, and what does 2FA actually add? The answer lies in the number and type of factors an attacker must possess.

#Something You Know, Have, and Are

The concept of multi-factor authentication is based on three categories:

• Something you know: a password or PIN.
• Something you have: a smartphone with Google Authenticator, a hardware key such as a YubiKey.
• Something you are: biometrics such as a fingerprint or face.

A leaked password is no longer enough to get in when the second layer is something you have — an attacker needs a physical device that is hard to duplicate. This is the core of 2FA: two factors from different categories, not two passwords.

#Mitigating Automated Attacks

Because TOTP codes change every 30 seconds and come from a separate device, credential stuffing that replays passwords becomes useless without the code. Automated attacks without access to the user's device will fail at the second layer, even when the first password has already leaked.

#The 2026 Trend: Passkeys as the New Direction

#TOTP's Role in the Modern Ecosystem

Since 2023, WebAuthn-based passkeys are officially supported by Google, Apple, and Microsoft as a password replacement. Instead of a shared secret, passkeys use an asymmetric key pair synced in vendor clouds, and technically render phishing powerless because a signature is only valid for the origin domain.

But TOTP hasn't disappeared. Many platforms still treat TOTP as the universal fallback because it requires no cloud sync or trust in a specific vendor, and works fully offline. In 2026, the most common pattern is offering both: passkeys for new users, TOTP for cross-device compatibility.

#Why Passwords Aren't Dead Yet

Despite being weak, passwords remain the first door because they're cheap and understood by everyone. 2FA bridges this transition: the password stays, but it's no longer the only key. Understanding this historical context helps you explain to users why an application demands an extra verification step beyond the password.

#Official Learning Resources

To deepen your knowledge of the history and standards, the three most authoritative documents are RFC 4226 and RFC 6238 for the OTP mechanisms, plus NIST SP 800-63B for policy. Read the test vector sections of both RFCs — we'll use the sample numbers there as our test oracle in episode 16.

Make these documents your reference point whenever you doubt otplib's behavior: the standard is always the source of truth, while the library is merely an implementation of that standard.

#Compliance: Why Enterprise Must Use 2FA

#SOC 2, ISO 27001, and Enterprise Questionnaires

Many companies first realize 2FA matters when answering security questionnaires from clients. SOC 2 and ISO 27001 generally expect multi-factor access controls for systems that touch sensitive data, and SaaS vendors are asked directly about their MFA adoption. A "no" often means losing the tender. Episode 18 will cover enforcement and compliance in more depth from an administrative point of view.

#Conclusion

Episode 1 mapped out the big picture of authentication: weak passwords, fragile SMS OTPs, reliable TOTP, and WebAuthn passkeys as the modern direction. You also got to know RFC 4226, RFC 6238, NIST SP 800-63B, and OWASP — four pillars that will support the whole implementation in this series.

The key takeaways:

• A password is only one factor and is vulnerable to credential stuffing, brute-force, and phishing.
• SMS OTP is weak due to SIM swapping and carrier interception.
• TOTP (RFC 6238) computes a code from time and a shared secret, safe to use offline.
• WebAuthn passkeys are the modern, phishing-resistant direction.
• NIST SP 800-63B and the OWASP Authentication Cheat Sheet serve as implementation references.
• 2FA is needed for attack mitigation and SOC 2, ISO 27001 compliance.

In the next episode, episode 2, we will dissect the basic TOTP concepts and its main architecture — how the Base32 shared secret, the time counter, and HMAC-SHA1 combine to produce 6 digits, plus the architectural flow from enrollment to a two-step login. Equip yourself with the otplib you installed in episode 0!