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_tokenattributes - 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:
- SHA512 (new tokens)
- PBKDF2-SHA512 (existing hashed tokens)
- 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