Plaintext OAuth Token Storage: A Silent Security Risk in Your Application

Introduction

Authentication credentials are the keys to your digital kingdom. When OAuth tokens and API keys are stored insecurely, you're essentially leaving those keys under the doormat. This vulnerability, recently patched in a popular application's authentication module, highlights a critical but often overlooked security concern: how we store sensitive credentials matters just as much as how we transmit them.

Developers frequently focus on securing credentials in transit using HTTPS and TLS, but forget that credentials at rest require equal protection. This oversight can turn a user's local machine into a treasure trove for attackers, malware, or even curious insiders.

The Vulnerability Explained

What Was Happening?

The vulnerability existed in the OAuth2 authentication plugin, specifically in the store.ts file's getToken and setToken functions. These functions were responsible for persisting OAuth tokens and API keys to the local filesystem—but they were doing so in plaintext.

Here's what the vulnerable code pattern looked like:

// Vulnerable code pattern (simplified)
function setToken(token: string, apiKey: string) {
  // Writing credentials directly to filesystem
  fs.writeFileSync('credentials.json', JSON.stringify({
    oauth_token: token,
    api_key: apiKey
  }));
}

function getToken() {
  // Reading plaintext credentials
  const data = fs.readFileSync('credentials.json', 'utf-8');
  return JSON.parse(data);
}

The Real Problem

The irony? The application already had PBKDF2 (Password-Based Key Derivation Function 2) available in its Rust dependencies at src-tauri/Cargo.lock:3809. This cryptographic function was sitting unused while sensitive credentials were being written to disk in a format anyone could read.

How Could This Be Exploited?

Let's walk through a realistic attack scenario:

Scenario: The Malicious Browser Extension

1. Initial Access: A user installs a seemingly innocent browser extension or downloads malware disguised as legitimate software
2. File System Scanning: The malicious code scans common application data directories for configuration files
3. Credential Harvesting: It discovers the plaintext credentials file and exfiltrates the OAuth tokens and API keys
4. Account Takeover: The attacker uses these tokens to:
   - Access the victim's account without needing their password
   - Make API calls on behalf of the user
   - Access sensitive data or resources
   - Potentially pivot to other connected services

Additional Attack Vectors:

• Physical Access: Someone with temporary physical access to an unlocked computer could copy credential files
• Backup Exposure: Plaintext credentials in cloud-synced folders or backups become accessible to anyone who compromises those services
• Insider Threats: System administrators or other users with file system access could harvest credentials
• Ransomware Exfiltration: Modern ransomware often exfiltrates data before encryption—plaintext credentials are prime targets

Real-World Impact

The severity rating of "medium" might seem modest, but the impact can be severe:

• Immediate Account Compromise: No password cracking needed—tokens provide direct access
• Lateral Movement: OAuth tokens often grant access to multiple services and APIs
• Long-lived Tokens: Many OAuth implementations use long-lived refresh tokens, extending the window of vulnerability
• Compliance Violations: Plaintext credential storage violates PCI DSS, GDPR, SOC 2, and other security standards

The Fix

What Changed?

The fix involved implementing proper encryption for stored credentials using the already-available PBKDF2 cryptographic function. Here's what a secure implementation looks like:

// Secure implementation (example)
import { pbkdf2Sync, randomBytes, createCipheriv, createDecipheriv } from 'crypto';

const ALGORITHM = 'aes-256-gcm';
const SALT_LENGTH = 32;
const KEY_LENGTH = 32;
const IV_LENGTH = 16;
const TAG_LENGTH = 16;

function deriveKey(password: string, salt: Buffer): Buffer {
  // Use PBKDF2 to derive encryption key
  return pbkdf2Sync(password, salt, 100000, KEY_LENGTH, 'sha256');
}

function setToken(token: string, apiKey: string, masterPassword: string) {
  const salt = randomBytes(SALT_LENGTH);
  const iv = randomBytes(IV_LENGTH);
  const key = deriveKey(masterPassword, salt);

  const cipher = createCipheriv(ALGORITHM, key, iv);

  const credentials = JSON.stringify({
    oauth_token: token,
    api_key: apiKey
  });

  let encrypted = cipher.update(credentials, 'utf8', 'hex');
  encrypted += cipher.final('hex');

  const authTag = cipher.getAuthTag();

  // Store salt, IV, auth tag, and encrypted data
  const secureData = {
    salt: salt.toString('hex'),
    iv: iv.toString('hex'),
    authTag: authTag.toString('hex'),
    encrypted: encrypted
  };

  fs.writeFileSync('credentials.enc', JSON.stringify(secureData));
}

function getToken(masterPassword: string) {
  const data = JSON.parse(fs.readFileSync('credentials.enc', 'utf-8'));

  const salt = Buffer.from(data.salt, 'hex');
  const iv = Buffer.from(data.iv, 'hex');
  const authTag = Buffer.from(data.authTag, 'hex');
  const key = deriveKey(masterPassword, salt);

  const decipher = createDecipheriv(ALGORITHM, key, iv);
  decipher.setAuthTag(authTag);

  let decrypted = decipher.update(data.encrypted, 'hex', 'utf8');
  decrypted += decipher.final('utf8');

  return JSON.parse(decrypted);
}

Security Improvements

The fix provides multiple layers of security:

1. PBKDF2 Key Derivation: Transforms a master password into a strong encryption key using 100,000 iterations, making brute-force attacks computationally expensive

2. AES-256-GCM Encryption: Uses authenticated encryption to protect both confidentiality and integrity of stored credentials

3. Unique Salts and IVs: Each encryption operation uses random salt and initialization vectors, preventing rainbow table attacks

4. Authentication Tags: GCM mode provides built-in authentication, detecting any tampering with encrypted data

Conclusion

The discovery and remediation of this plaintext credential storage vulnerability serves as an important reminder: security is not just about what you build, but how you build it. Having cryptographic capabilities available in your dependencies means nothing if they're not properly utilized.

Key takeaways for developers:

1. Always encrypt sensitive data at rest, not just in transit
2. Leverage existing security libraries rather than rolling your own crypto
3. Use operating system credential managers when available
4. Implement defense in depth with multiple security layers
5. Regular security audits can catch these issues before they're exploited

Remember, every plaintext credential is a potential breach waiting to happen. The few extra lines of code to implement proper encryption could save your users—and your organization—from a devastating security incident.

Stay secure, encrypt your secrets, and always assume that local storage is accessible to attackers. Your users' security depends on it.

Have you found similar vulnerabilities in your codebase? Share your experiences and lessons learned in the comments below. And remember: when in doubt, encrypt!