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

Prevention & Best Practices

Never Store Credentials in Plaintext

This should be a fundamental rule, but it's worth emphasizing: sensitive data at rest must be encrypted. This applies to:

• OAuth tokens and refresh tokens
• API keys and secrets
• Session identifiers
• Personal identifiable information (PII)
• Any data that could facilitate unauthorized access

Use Operating System Credential Managers

Modern operating systems provide secure credential storage mechanisms:

• Windows: Credential Manager (DPAPI)
• macOS: Keychain Services
• Linux: Secret Service API (libsecret) or GNOME Keyring

// Example using electron-store with encryption
import Store from 'electron-store';

const store = new Store({
  encryptionKey: 'your-encryption-key',
  name: 'secure-credentials'
});

// Credentials are automatically encrypted
store.set('oauth_token', token);

Implement Defense in Depth

Don't rely on a single security measure:

1. Encrypt credentials using strong algorithms (AES-256)
2. Restrict file permissions to prevent unauthorized access
3. Use secure key derivation (PBKDF2, Argon2, scrypt)
4. Implement token rotation to limit exposure windows
5. Add tamper detection using HMACs or authenticated encryption
6. Audit access to credential storage locations

Security Testing and Detection

Use these tools and techniques to identify similar vulnerabilities:

Static Analysis Tools:
- Semgrep: Detect plaintext credential storage patterns
- SonarQube: Identify security hotspots in credential handling
- GitGuardian: Scan for exposed secrets in repositories

Example Semgrep Rule:

rules:
  - id: plaintext-credential-storage
    pattern: fs.writeFileSync($FILE, $CREDS)
    message: "Potential plaintext credential storage detected"
    severity: WARNING
    languages: [typescript, javascript]

Manual Code Review Checklist:
- [ ] Are credentials encrypted before writing to disk?
- [ ] Is a strong encryption algorithm used (AES-256)?
- [ ] Are encryption keys properly derived (PBKDF2/Argon2)?
- [ ] Are salts and IVs randomly generated per operation?
- [ ] Are file permissions restricted appropriately?
- [ ] Is there tamper detection (HMAC/authenticated encryption)?

Relevant Security Standards

This vulnerability relates to several security standards and guidelines:

• OWASP Top 10 2021: A02:2021 – Cryptographic Failures
• CWE-312: Cleartext Storage of Sensitive Information
• CWE-522: Insufficiently Protected Credentials
• NIST SP 800-63B: Digital Identity Guidelines (Authentication and Lifecycle Management)
• PCI DSS Requirement 3.4: Render PAN unreadable anywhere it is stored

Additional Resources

• OWASP Cryptographic Storage Cheat Sheet
• NIST Guidelines on Key Derivation Functions
• OAuth 2.0 Security Best Current Practice

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!