What Is 2FA (Two-Factor Authentication)?

Introduction

2FA (two-factor authentication) is a way to make login depend on two different kinds of proof instead of one. That sounds simple, but the important part is not the number two. The important part is independence. If an attacker can steal your password with a phishing page, malware, a database breach, or password reuse, then a password-only account is already in trouble. A second factor helps only if it forces the attacker to solve a different problem.

That is why 2FA is so widely used on exchanges, wallets, email accounts, banking apps, and enterprise systems. In practice, the first factor is often a password, and the second is often a code from an authenticator app, a push approval, or a security key. But those choices are not equally strong. Some second factors can still be phished or socially engineered. Others are designed so the secret never leaves the device and cannot be replayed at a fake site.

A useful way to think about authentication is this: a login system is trying to answer the question, “Is this really the legitimate user right now?” A password answers that by asking for a memorized secret. 2FA asks for an additional proof from a different channel or device. If the two proofs fail in different ways, the attacker’s job becomes much harder. If they fail in the same way, you may have added friction more than security.

NIST, in SP 800-63B, frames this as a matter of authentication assurance. Higher assurance means an attacker needs stronger capabilities and more effort to successfully impersonate a user. At higher assurance levels, merely adding some second step is not enough. The method must also resist replay, phishing, and verifier impersonation.

How do you tell if a method is a true second factor?

People often say “2FA” when they really mean “an extra login step.” Those are not always the same thing. Two passwords are not two factors. A password plus a PIN is still usually the same factor category: something you know. The system asked for two secrets, but both are vulnerable to the same basic failure mode; theft or disclosure of knowledge.

A real second factor comes from a different evidence class. In ordinary deployments, the most relevant classes are something you know such as a password or PIN, something you have such as a phone or hardware token, and something you are such as a biometric. NIST allows biometrics only as part of multi-factor authentication with a physical authenticator, which reflects an important fact: a fingerprint alone is not a secret in the same way a private key or password is. Biometrics are useful for unlocking or activating another authenticator, not as a universal stand-alone answer.

So the key question is not “How many prompts did the user see?” It is “How many independent barriers does the attacker have to cross?” If a fake website can trick you into typing both your password and your six-digit code, then the factors are formally different, but the login is still vulnerable to phishing. If a security key signs a challenge that is bound to the real website’s domain, that attack breaks differently.

This distinction matters a great deal in crypto and financial systems. If an exchange account protects withdrawals with password plus SMS code, that is better than password alone against credential stuffing. But it is still exposed to SIM swaps, telecom compromise, and phishing kits that relay codes in real time. If the same account uses a phishing-resistant authenticator such as a FIDO security key, the attacker can no longer win by simply collecting credentials at a fake site.

How does two-factor authentication stop common password attacks?

Here is the mechanism in plain terms. Suppose an attacker obtains your password from a breach or from reuse on another site. In a password-only system, that single event is often enough to log in. In a 2FA system, the stolen password proves only one thing: the attacker has compromised the knowledge factor. The system still asks for proof of possession of a device, or for a cryptographic response from a registered authenticator.

That changes the economics of attack. Credential stuffing works because passwords are cheap to test at scale. A second factor is harder to automate, often harder to steal remotely, and usually tied to a particular user session. So 2FA does not make compromise impossible, but it forces attackers away from cheap mass attacks and toward more targeted methods such as phishing, social engineering, malware, session theft, or account recovery abuse.

This is why MFA is so effective against password attacks even when it is imperfect. OWASP summarizes the practical point well: the biggest gain comes from stopping brute-force attacks, password spraying, and reuse of leaked passwords. Those are common because they are scalable. 2FA removes that scale advantage when the second factor is correctly implemented.

But the same mechanism also explains the limits. If the second factor can be intercepted, relayed, or approved under pressure, then the attacker has simply shifted from stealing one secret to stealing a secret plus an ephemeral proof. That is still an improvement, but not the strongest kind.

How do HOTP and TOTP one-time passwords work?

The most widely deployed form of 2FA is the one-time password, or OTP. The idea is straightforward: instead of entering only your usual password, you also enter a short code that is valid for one use or one short time window. Because the code changes frequently, a stolen code is less useful than a static password.

There are two major families behind common authenticator-app codes. The older family is HOTP, defined in RFC 4226. HOTP is event-based: the token and the server share a secret key K and a counter C. Each time a new OTP is generated, the counter advances. The server computes the same function and checks whether the presented code matches the expected counter state, often with a small look-ahead window to tolerate desynchronization.

The better-known family today is TOTP, defined in RFC 6238. TOTP keeps the same basic idea but replaces the counter with time. Instead of HOTP using an event counter, TOTP computes TOTP = HOTP(K, T), where T is derived from the current Unix time, a starting time T0, and a time step X. In practice, X is commonly 30 seconds. That is why authenticator apps show a code that refreshes every half minute.

The intuition is simple. During a given 30-second window, both your authenticator app and the server can independently compute the same short code from the same shared secret and the same current time window. No network call to the authenticator app is required. That makes TOTP convenient and cheap to deploy.

A worked example makes the mechanism clearer. Imagine you enable 2FA on an exchange. During setup, the exchange generates a random shared secret and encodes it in a QR code. Your authenticator app scans that QR code and stores the secret locally. Later, when you log in, the exchange asks for the six-digit TOTP code. At that moment, your phone computes the current code from the shared secret plus the current 30-second time slice. The exchange computes what it expects from its copy of the same secret. If the values match, the exchange concludes that whoever is logging in likely possesses the enrolled device or at least the enrolled secret.

That last phrase matters. TOTP proves possession of the shared secret, not necessarily possession of a tamper-proof hardware device. If the QR secret was copied during enrollment, or later extracted from the device, an attacker can generate the same codes elsewhere. This is one reason OTP apps are useful but not the highest-assurance option.

The standards make the tradeoffs explicit. RFC 6238 recommends a 30-second step as a balance between security and usability. Validators may allow a small time-skew window so minor clock drift does not lock users out, but every extra accepted time step slightly enlarges the attacker’s chance of success. RFC 4226 gives a rough approximation of brute-force risk as Sec = s*v / 10^Digit, where s is the acceptance window, v is the number of attempts, and Digit is the number of OTP digits. The consequence is direct: longer codes, tighter windows, and stricter rate limits reduce attack success.

That is also why OTPs must be treated like real secrets. NIST and OWASP guidance converge on the operational basics: they should be short-lived, single-use, rate-limited, invalidated on successful use, and not logged or stored carelessly. RFC 6238 is explicit that once an OTP has been accepted successfully, the verifier must not accept it again. Without that rule, a captured code could be replayed within the same time window.

Why is SMS-based 2FA weaker than authenticator apps?

SMS-based 2FA became popular because everyone has a phone number and text messages are easy to deliver. The weakness is structural: the phone number is not a cryptographic device under the control of the relying party. It is part of a telecom identity system with its own staff, procedures, recovery paths, and attack surface.

That is why SMS helps against some attacks and fails badly against others. If an attacker only has your reused password from a breach, an SMS code may stop them. But if the attacker can socially engineer your mobile carrier, perform a SIM swap, compromise your phone’s message access, or trick you into reading a code on a phishing page, the second factor is no longer independent enough.

The FBI’s IC3 has warned that SIM-swapping incidents have been used to intercept SMS-based 2FA and reset accounts. This is not just a theoretical weakness. It reflects the fact that the second factor depends on control of a phone number, and control of a phone number can be reassigned by processes outside the application’s own trust boundary.

NIST’s position is correspondingly cautious. SP 800-63B prohibits email as an out-of-band authentication channel and treats PSTN-based out-of-band methods such as SMS or voice as restricted, requiring additional controls and risk assessment. That is not the same as saying SMS is useless. It means SMS should be understood as a lower-assurance method whose failure modes are well known.

Authenticator apps are usually better than SMS because the OTP secret lives on the device and does not travel through the phone network each time. They avoid SIM-swap risk and often work offline. But they still remain vulnerable to real-time phishing and secret theft if the device or provisioning flow is compromised.

When do push-based approvals fail and how do you mitigate MFA fatigue?

Push-based 2FA tries to improve usability. Instead of asking users to transcribe a six-digit code, it sends a prompt to a registered device asking the user to approve or deny the login. In principle, that sounds stronger because the user sees a live request tied to a login attempt.

In practice, the security depends heavily on the design of the prompt. If the prompt is just “Approve sign-in?” with no context, attackers can spam it until the user taps yes out of confusion or annoyance. CISA and partner agencies have described this as MFA bombing or MFA fatigue: repeated prompts are sent until the victim accepts one.

The mechanism here is subtle but important. The cryptography may be fine; the weak point is the user decision channel. A human being under interruption is acting as the verifier of intent. If the system gives poor context, unlimited retries, or weak rate controls, the attacker can turn persistence into an authentication bypass.

This is why better push systems show context such as location, device, or a number-matching challenge, and why stronger systems move away from generic approvals toward cryptographic, phishing-resistant authenticators. The lesson is not that push is always bad. It is that usable approval is not the same thing as secure approval.

What makes an authenticator phishing-resistant?

The biggest misunderstanding about 2FA is that all second factors resist phishing. They do not. A six-digit TOTP code can be entered into a fake website. A push prompt can be approved during a fraudulent session. An SMS code can be relayed in real time. In each of these cases, the attacker does not need to break the factor cryptographically. They only need to trick the user into delivering a valid authenticator output.

That is why modern guidance increasingly centers on phishing resistance rather than on the mere presence of a second factor. NIST defines phishing resistance as the ability of the authentication protocol to prevent disclosure of authentication secrets and valid authenticator outputs to an impostor verifier without relying on claimant vigilance. That final clause matters. Security should not depend entirely on the user noticing that a site is fake.

This is where FIDO2, WebAuthn, security keys, and passkeys enter the picture. Instead of asking the user to reveal a reusable secret or a relayed code, these systems use public-key cryptography. During registration, the authenticator creates an asymmetric key pair for a specific relying party. The private key stays in the authenticator. The public key is stored by the server. During login, the server sends a challenge, and the authenticator signs it; but only for the correct relying party origin.

The scoping is the crucial mechanism. WebAuthn credentials are bound to the relying party, and user agents and authenticators enforce that scoping. So if a phishing site at the wrong domain asks for authentication, the authenticator does not produce a valid assertion for the legitimate site. The user is not being asked to copy a secret from one place to another. The browser, authenticator, and server cooperate to ensure the signature is only useful in the right context.

A concrete example shows why this is different from OTP. Suppose a user visits fake-exchange.example that imitates a real exchange. With password plus TOTP, the fake site can collect the password and current six-digit code, then immediately relay both to the real exchange. With WebAuthn, the fake site cannot obtain a valid signature for the real exchange’s relying-party identity. The user may still be fooled visually, but the authenticator output will not verify at the real site. The attack fails at the protocol layer rather than at the human-awareness layer.

This is why NIST requires phishing-resistant authenticators at AAL3 and requires verifiers at AAL2 to offer at least one phishing-resistant option. The field has learned the hard way that “extra step” is not the same thing as “impostor-resistant.”

How do passkeys and security keys provide built-in multi‑factor authentication?

Passkeys can seem confusing because they blur the line between “second factor” and “passwordless login.” The reason is that a single passkey-based authentication event can satisfy multiple factor requirements at once. The authenticator proves possession of the private key, and it may also require user verification locally through a biometric or PIN before using that key.

In other words, the system can combine “something you have” with “something you know” or “something you are” inside one cryptographic ceremony. FIDO guidance notes that many relying parties do not combine passkeys with additional factors because a passkey with required user verification can already serve as multi-factor authentication for their use case.

That does not mean all passkeys are identical. Some are device-bound; others are syncable across devices through a passkey provider. NIST draws a sharp line at the highest assurance level: AAL3 requires a cryptographic authenticator with a non-exportable private key, so syncable authenticators are not allowed there. The reason is straightforward. If a private key can be exported for syncing, then the assurance model is no longer based on one hardware-contained key that cannot leave the authenticator boundary.

This is a good example of where design choices reflect threat models. Syncing improves usability and recovery. Non-exportability improves assurance against certain compromises. Neither property is “the point” in every environment. The right choice depends on how much recovery convenience you need and how much key isolation you require.

How should account recovery be designed to preserve strong 2FA?

A strong login flow can still be undermined by a weak recovery flow. If an attacker cannot get past your security key but can call support, answer weak recovery questions, and replace the factor with email or SMS, then the effective security of the account is determined by the recovery path, not the login prompt.

This is why recovery should be treated as part of authentication, not as an afterthought. FIDO’s recovery guidance recommends reducing recovery needs first by encouraging multiple authenticators per account. If a user registers both a phone-based passkey and a hardware security key, losing one device does not immediately force a fragile fallback.

When recovery is necessary, the fallback should not be weaker than the authenticator being recovered. That principle sounds obvious, but many systems violate it. A high-assurance login with a phishing-resistant authenticator loses much of its value if the same account can be reclaimed through a low-assurance email link or easily hijacked phone number.

For crypto users, this issue is especially important because account recovery and withdrawal protection often intersect. Exchanges may use 2FA not only for sign-in but also for withdrawals, API key changes, or security-setting changes. Those high-impact actions should be protected at least as strongly as login, often more strongly.

What security risks does 2FA not protect against?

2FA is powerful, but it is not a universal account-security cure. NIST is explicit that these protections are meant to mitigate credential theft, not to stop a user from willingly disclosing secrets. If a victim is persuaded to hand over a code, approve a push, or authenticate on behalf of an attacker, the protocol can only do so much unless it is phishing-resistant by construction.

2FA also does not solve malware on an already compromised device, theft of session tokens after login, or attacks against service accounts that cannot easily use interactive MFA. CISA notes that attackers target long-lived session tokens and non-human accounts precisely because these may bypass MFA altogether. So strong authentication must be paired with session management, token hygiene, device security, and monitoring.

Even ordinary configuration choices matter. Session lifetimes that are too long increase the value of a stolen token. Factor replacement without reauthentication creates an attacker-controlled bypass path. Excessive OTP retry windows expand brute-force success. Security is not only the authenticator type; it is also the surrounding operating rules.

Conclusion

2FA works because it forces an attacker to defeat two independent proofs instead of one. That is the idea worth remembering. Everything else follows from it.

If the second factor is easy to relay, socially engineer, or reissue, then 2FA still helps, but its protection is partial. If the authenticator is cryptographic and phishing-resistant, the system stops a much broader class of attacks at the protocol layer rather than hoping the user notices them. So the real question is not whether you have 2FA. It is what kind of second factor you have, what attacks it changes, and whether your recovery path quietly undoes the benefit.

How do you use two-factor authentication to protect your trading account?

Use two-factor authentication to protect your trading account by enabling the strongest second factor Cube offers and by treating recovery material as part of your security plan. On Cube, prefer phishing-resistant options (security keys or passkeys) when available, register at least one backup authenticator, and store recovery codes or backups offline.

1. Open your Cube account security options and register the strongest second factor available (prefer a security key / passkey / WebAuthn option).
2. Add a secondary authenticator (an authenticator app or a second hardware key) and verify it by performing a test sign-in.
3. Download or generate recovery/backup codes and store them offline in an encrypted password manager or a printed copy in a locked safe (do not keep them in email).
4. For withdrawals or other high-value actions, always re-authenticate using your strongest factor and verify destination addresses or beneficiary details before approving.