Migrate OAuth token hashing from PBKDF2-SHA512 to SHA512 for FIPS compliance

Summary

This MR migrates OAuth access token hashing from PBKDF2-SHA512 to SHA512 to resolve authentication failures in Ubuntu 22.04 FIPS environments where OpenSSL enforces minimum 16-byte salt requirements for PBKDF2.

What does this MR do?

  • Replaces PBKDF2-SHA512 with SHA512 for new OAuth token hashing
  • Implements fallback support: SHA512 → PBKDF2-SHA512 → Plain text
  • Updates test suites to use plaintext_token attributes
  • Adds comprehensive test coverage for fallback mechanisms

Why was this MR needed?

Current PBKDF2 implementation uses empty salts, which are rejected by FIPS-compliant OpenSSL. This prevents Git operations using OAuth tokens in Ubuntu 22.04 FIPS environments.

Why SHA512 is appropriate:

  • OAuth tokens have 256 bits entropy from SecureRandom.urlsafe_base64(32)
  • 2-hour expiration with automatic rotation
  • SHA512 is FIPS 140-3 compliant and ~10,000x faster than PBKDF2
  • Security teams confirmed PBKDF2 is unnecessary for cryptographically random tokens

Implementation Details

New configuration:

# Before
hash_token_secrets using: '::Gitlab::DoorkeeperSecretStoring::Token::Pbkdf2Sha512', fallback: :plain

# After  
hash_token_secrets using: '::Gitlab::DoorkeeperSecretStoring::Token::Sha512Hash', fallback: '::Gitlab::DoorkeeperSecretStoring::Token::Pbkdf2Sha512'

Fallback Strategy:

  1. SHA512 (new tokens)
  2. PBKDF2-SHA512 (existing hashed tokens)
  3. Plain text (supports SM instances migrating from very old GitLab versions)

Migration Strategy

  • New tokens: SHA512 hashed
  • Existing tokens: Work via fallback lookup
  • Zero downtime: Natural migration as tokens expire (2-hour lifecycle)

Acceptance Criteria

  • OAuth authentication works in Ubuntu 22.04 FIPS environments
  • New tokens use SHA512 hashing
  • Backward compatibility maintained via fallback
  • No breaking changes

Performance Impact

Positive: SHA512 provides ~10,000x faster token lookups compared to PBKDF2.

References

Fixes: #551165 (closed)

Screenshots or screen recordings

Before After

How to set up and validate locally

MR acceptance checklist

Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.

Edited by Aboobacker MK

Merge request reports

Loading