Two-Factor Authentication Implementation: SMS, TOTP, and Hardware Keys Compared

Passwords alone no longer provide adequate account protection. Users reuse passwords across sites, fall for phishing attacks, and choose weak credentials despite warnings. Two-factor authentication (2FA) adds a second verification layer that significantly reduces account compromise even when passwords are exposed.

Implementing 2FA requires balancing security strength against user friction. The most secure options add complexity. The most convenient options have known weaknesses. Understanding the trade-offs enables appropriate choices for different user populations and risk levels.

Understanding 2FA Factors

Authentication factors fall into three categories:

Something you know - Passwords, PINs, security questions

Something you have - Phone, hardware key, smart card

Something you are - Fingerprint, face recognition, voice

Two-factor authentication combines factors from different categories. Password plus SMS code uses knowledge and possession. Password plus fingerprint uses knowledge and inherence.

Combining factors from the same category provides weaker protection. Password plus security question both rely on knowledge that can be stolen or guessed.

SMS-Based Verification

SMS verification sends a code to the user’s phone number. Despite known weaknesses, it remains widely used due to simplicity and universal phone availability.

Implementation

const twilio = require('twilio');

const client = twilio(
  process.env.TWILIO_ACCOUNT_SID,
  process.env.TWILIO_AUTH_TOKEN
);

// Generate and send code
async function sendSmsCode(phoneNumber) {
  const code = generateSecureCode(6);
  const expiresAt = Date.now() + 10 * 60 * 1000; // 10 minutes
  
  // Store code for verification
  await db.verificationCodes.insertOne({
    phoneNumber,
    code: hashCode(code), // Store hashed
    expiresAt,
    attempts: 0,
  });
  
  // Send via SMS
  await client.messages.create({
    body: `Your verification code is: ${code}`,
    from: process.env.TWILIO_PHONE_NUMBER,
    to: phoneNumber,
  });
  
  return { success: true };
}

// Verify submitted code
async function verifySmsCode(phoneNumber, submittedCode) {
  const record = await db.verificationCodes.findOne({
    phoneNumber,
    expiresAt: { $gt: Date.now() },
  });
  
  if (!record) {
    return { valid: false, error: 'Code expired or not found' };
  }
  
  // Rate limit attempts
  if (record.attempts >= 3) {
    await db.verificationCodes.deleteOne({ _id: record._id });
    return { valid: false, error: 'Too many attempts' };
  }
  
  await db.verificationCodes.updateOne(
    { _id: record._id },
    { $inc: { attempts: 1 } }
  );
  
  if (!verifyHashedCode(submittedCode, record.code)) {
    return { valid: false, error: 'Invalid code' };
  }
  
  // Clean up used code
  await db.verificationCodes.deleteOne({ _id: record._id });
  
  return { valid: true };
}

function generateSecureCode(length) {
  const crypto = require('crypto');
  const max = Math.pow(10, length);
  const randomNum = crypto.randomInt(0, max);
  return randomNum.toString().padStart(length, '0');
}

SMS Strengths

Universal availability - Works on any phone, no app installation required.

User familiarity - Most users have received SMS codes and understand the process.

Simple implementation - Well-documented APIs from providers like Twilio.

SMS Weaknesses

SIM swapping attacks - Attackers convince carriers to transfer phone numbers to attacker-controlled SIMs.

SS7 vulnerabilities - Telecom infrastructure weaknesses allow message interception.

Phishing susceptibility - Users can be tricked into entering codes on fake sites.

Delivery reliability - Messages sometimes delay or fail entirely.

International costs - Sending SMS globally incurs significant costs.

When SMS is Appropriate

• Low to medium security applications
• User bases unfamiliar with authenticator apps
• Fallback option when stronger methods unavailable
• Initial 2FA rollout before migrating to stronger options

TOTP Authenticator Apps

Time-based One-Time Passwords (TOTP) generate codes locally on user devices. Apps like Google Authenticator, Authy, and 1Password support this standard.

How TOTP Works

1. Server generates a secret key
2. User adds secret to authenticator app (usually via QR code)
3. App and server independently generate matching codes every 30 seconds
4. User enters current code to verify

The RFC 6238 specification defines the algorithm. Both parties derive codes from shared secret and current time.

Implementation

const speakeasy = require('speakeasy');
const qrcode = require('qrcode');

// Generate secret for new user
async function setupTotp(userId) {
  const secret = speakeasy.generateSecret({
    name: `MyApp (${userId})`,
    issuer: 'MyApp',
    length: 32,
  });
  
  // Store secret (encrypted) for later verification
  await db.users.updateOne(
    { _id: userId },
    {
      $set: {
        totpSecret: encrypt(secret.base32),
        totpEnabled: false, // Enable after verification
      }
    }
  );
  
  // Generate QR code for authenticator app
  const qrCodeUrl = await qrcode.toDataURL(secret.otpauth_url);
  
  return {
    secret: secret.base32,
    qrCode: qrCodeUrl,
    // Also provide manual entry option
    manualEntry: {
      secret: secret.base32,
      algorithm: 'SHA1',
      digits: 6,
      period: 30,
    }
  };
}

// Verify TOTP code
async function verifyTotp(userId, code) {
  const user = await db.users.findById(userId);
  
  if (!user.totpSecret) {
    return { valid: false, error: 'TOTP not configured' };
  }
  
  const secret = decrypt(user.totpSecret);
  
  const valid = speakeasy.totp.verify({
    secret: secret,
    encoding: 'base32',
    token: code,
    window: 1, // Allow 1 period before/after for clock drift
  });
  
  return { valid };
}

// Complete TOTP setup after user verifies first code
async function confirmTotpSetup(userId, code) {
  const result = await verifyTotp(userId, code);
  
  if (result.valid) {
    // Generate backup codes
    const backupCodes = await generateBackupCodes(userId);
    
    await db.users.updateOne(
      { _id: userId },
      { $set: { totpEnabled: true } }
    );
    
    return { success: true, backupCodes };
  }
  
  return { success: false, error: 'Invalid code' };
}

// Generate one-time backup codes
async function generateBackupCodes(userId) {
  const codes = [];
  
  for (let i = 0; i < 10; i++) {
    const code = crypto.randomBytes(4).toString('hex');
    codes.push(code);
  }
  
  // Store hashed backup codes
  const hashedCodes = codes.map(code => ({
    hash: hashCode(code),
    used: false,
  }));
  
  await db.users.updateOne(
    { _id: userId },
    { $set: { backupCodes: hashedCodes } }
  );
  
  return codes; // Return plaintext codes once for user to save
}

TOTP Strengths

Phishing resistant - Codes tied to specific issuer in authenticator app.

Offline capable - Codes generate locally without network connectivity.

No message costs - No per-use charges like SMS.

Standardized - Works with any RFC 6238 compliant authenticator.

Multiple accounts - Single app manages codes for many services.

TOTP Limitations

Device dependency - Losing phone without backup codes locks out account.

Setup friction - Requires app installation and QR scanning.

Clock synchronization - Significant clock drift causes verification failures.

Shared secret risk - Server stores shared secret that could be compromised.

TOTP Best Practices

Require code verification before enabling - Confirm user successfully added secret before relying on it.

Provide backup codes - Generate one-time codes for recovery.

Show secret for manual entry - QR scanning sometimes fails; allow manual input.

Display issuer clearly - Help users identify correct account in their app.

Hardware Security Keys

Hardware keys like YubiKey provide the strongest authentication available. They implement FIDO2/WebAuthn standards for phishing-resistant verification.

How WebAuthn Works

1. Server generates a challenge
2. Browser prompts user to touch security key
3. Key signs challenge with private key (never leaves device)
4. Server verifies signature with stored public key

The private key cannot be extracted from the hardware device. Phishing fails because the key verifies the origin domain.

Implementation

// Server-side with @simplewebauthn/server
const {
  generateRegistrationOptions,
  verifyRegistrationResponse,
  generateAuthenticationOptions,
  verifyAuthenticationResponse,
} = require('@simplewebauthn/server');

const rpName = 'MyApp';
const rpID = 'myapp.com';
const origin = 'https://myapp.com';

// Start registration
async function startWebAuthnRegistration(userId) {
  const user = await db.users.findById(userId);
  
  // Get existing credentials to exclude
  const existingCredentials = user.webauthnCredentials || [];
  
  const options = await generateRegistrationOptions({
    rpName,
    rpID,
    userID: userId,
    userName: user.email,
    userDisplayName: user.name,
    attestationType: 'none', // or 'direct' for attestation
    excludeCredentials: existingCredentials.map(cred => ({
      id: cred.credentialID,
      type: 'public-key',
      transports: cred.transports,
    })),
    authenticatorSelection: {
      residentKey: 'preferred',
      userVerification: 'preferred',
    },
  });
  
  // Store challenge for verification
  await db.sessions.updateOne(
    { userId },
    { $set: { webauthnChallenge: options.challenge } }
  );
  
  return options;
}

// Complete registration
async function completeWebAuthnRegistration(userId, response) {
  const session = await db.sessions.findOne({ userId });
  
  const verification = await verifyRegistrationResponse({
    response,
    expectedChallenge: session.webauthnChallenge,
    expectedOrigin: origin,
    expectedRPID: rpID,
  });
  
  if (!verification.verified) {
    return { success: false, error: 'Verification failed' };
  }
  
  const { credentialID, credentialPublicKey, counter } = verification.registrationInfo;
  
  // Store credential
  await db.users.updateOne(
    { _id: userId },
    {
      $push: {
        webauthnCredentials: {
          credentialID: Buffer.from(credentialID),
          credentialPublicKey: Buffer.from(credentialPublicKey),
          counter,
          transports: response.response.transports,
          createdAt: new Date(),
        }
      }
    }
  );
  
  return { success: true };
}

// Start authentication
async function startWebAuthnAuthentication(userId) {
  const user = await db.users.findById(userId);
  
  const options = await generateAuthenticationOptions({
    rpID,
    allowCredentials: user.webauthnCredentials.map(cred => ({
      id: cred.credentialID,
      type: 'public-key',
      transports: cred.transports,
    })),
    userVerification: 'preferred',
  });
  
  await db.sessions.updateOne(
    { userId },
    { $set: { webauthnChallenge: options.challenge } }
  );
  
  return options;
}

// Complete authentication
async function completeWebAuthnAuthentication(userId, response) {
  const user = await db.users.findById(userId);
  const session = await db.sessions.findOne({ userId });
  
  const credential = user.webauthnCredentials.find(
    cred => cred.credentialID.equals(Buffer.from(response.id, 'base64url'))
  );
  
  if (!credential) {
    return { success: false, error: 'Credential not found' };
  }
  
  const verification = await verifyAuthenticationResponse({
    response,
    expectedChallenge: session.webauthnChallenge,
    expectedOrigin: origin,
    expectedRPID: rpID,
    authenticator: {
      credentialID: credential.credentialID,
      credentialPublicKey: credential.credentialPublicKey,
      counter: credential.counter,
    },
  });
  
  if (!verification.verified) {
    return { success: false, error: 'Verification failed' };
  }
  
  // Update counter to prevent replay attacks
  await db.users.updateOne(
    { _id: userId, 'webauthnCredentials.credentialID': credential.credentialID },
    { $set: { 'webauthnCredentials.$.counter': verification.authenticationInfo.newCounter } }
  );
  
  return { success: true };
}

Client-Side Implementation

// Using @simplewebauthn/browser
import {
  startRegistration,
  startAuthentication,
} from '@simplewebauthn/browser';

async function registerSecurityKey() {
  // Get options from server
  const optionsResponse = await fetch('/api/webauthn/register/start', {
    method: 'POST',
  });
  const options = await optionsResponse.json();
  
  // Prompt user to touch security key
  const credential = await startRegistration(options);
  
  // Send response to server
  const verifyResponse = await fetch('/api/webauthn/register/complete', {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify(credential),
  });
  
  return verifyResponse.json();
}

async function authenticateWithSecurityKey() {
  const optionsResponse = await fetch('/api/webauthn/authenticate/start', {
    method: 'POST',
  });
  const options = await optionsResponse.json();
  
  const credential = await startAuthentication(options);
  
  const verifyResponse = await fetch('/api/webauthn/authenticate/complete', {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify(credential),
  });
  
  return verifyResponse.json();
}

Hardware Key Strengths

Phishing immunity - Keys verify origin domain, rejecting fake sites.

No shared secrets - Server stores only public keys.

Tamper resistant - Private keys cannot be extracted from hardware.

Replay protection - Signature counters prevent reuse.

Cross-platform - Works on any device with USB, NFC, or Bluetooth.

Hardware Key Limitations

Cost - Users must purchase physical devices ($25-70 each).

Availability - Users cannot authenticate without physical key present.

Platform support - Older browsers and devices may lack WebAuthn support.

Backup complexity - Users should register multiple keys for redundancy.

Comparison and Recommendations

Aspect	SMS	TOTP	Hardware Keys
Phishing resistance	Low	Medium	High
User convenience	High	Medium	Medium
Setup complexity	Low	Medium	Medium
Cost per user	Ongoing	None	Upfront
Offline support	No	Yes	Yes
Lost device recovery	Easy	Backup codes	Backup keys

Recommended Approach

Minimum viable 2FA:

• Offer TOTP as primary option
• Provide backup codes for recovery
• Consider SMS as fallback only

Enhanced security:

• Support hardware keys for high-value accounts
• Require 2FA for administrative access
• Allow multiple methods per account

Enterprise requirements:

• Mandate hardware keys for privileged users
• Audit 2FA enrollment and usage
• Integrate with SSO providers

User Experience Considerations

Enrollment Flow

// Step-by-step enrollment with clear progress
const enrollmentSteps = [
  { id: 'choose', title: 'Choose Method', component: MethodSelector },
  { id: 'setup', title: 'Setup', component: SetupInstructions },
  { id: 'verify', title: 'Verify', component: VerificationForm },
  { id: 'backup', title: 'Save Backup Codes', component: BackupCodes },
  { id: 'complete', title: 'Complete', component: Confirmation },
];

Recovery Options

Always provide recovery paths:

• Backup codes generated during setup
• Secondary 2FA method
• Identity verification for account recovery
• Time-limited recovery tokens via email

Clear Communication

Explain 2FA benefits without jargon:

"Two-factor authentication adds an extra layer of security. 
Even if someone learns your password, they cannot access 
your account without also having your phone or security key."

Two-factor authentication represents one of the most effective security measures available. Starting with TOTP provides strong protection with reasonable user friction. Organizations with higher security requirements should encourage or require hardware security keys for their proven phishing resistance.