Oktaのキャッシュキー生成問題から学ぶ認証システム設計の教訓
はじめに
2024年10月、Oktaの認証システムにおいて新たな脆弱性が発見されました。
これは、AD/LDAPの認証結果をキャッシュする際に使用していた「キャッシュキー」の生成方法に起因し、特定の条件下ではユーザーがパスワードを入力せずとも認証が成功してしまうというものです。
この記事では、この脆弱性がどのように発生したのか、その技術的背景と、認証設計における重要な教訓について掘り下げます。
詳しい発表については、Oktaの公式発表もご覧ください。
脆弱性の原因：bcryptによるキャッシュキー生成と文字数制限
Oktaの発表によれば、ユーザー名が52文字以上の場合に脆弱性が発生するとのことです。
Oktaのキャッシュキーは「ユーザーID + ユーザー名 + パスワード」を一つの文字列にまとめてbcryptでハッシュ化することで生成されていましたが、bcryptには「入力が72文字を超えるとそれ以降が切り捨てられる」という仕様があります。そのため、ユーザー名が長い場合にパスワードがハッシュに含まれず、認証が正しく行われないケースが発生したと考えられます。
Oktaの対応：PBKDF2への移行
Oktaは、この問題への対応として、キャッシュキーの生成アルゴリズムをbcryptからPBKDF2へと変更しました。
PBKDF2はパスワード保護に適したアルゴリズムであり、bcryptのような文字数制限がないため、長いユーザー名を含む場合でも問題なくハッシュが生成され、キャッシュキーの一意性が保たれるようになりました。
教訓：適切なアルゴリズム選択の重要性
この事例は、システム設計におけるハッシュアルゴリズム選択の重要性を強く示唆しています。bcryptはパスワードのハッシュ化には優れていますが、キャッシュキーのように長い入力を必要とするケースには適していません。
認証キャッシュ用途には、文字数の制限のないPBKDF2やSHA-256のようなアルゴリズムが適しています。
ただし、PBKDF2やSHA-256はソルトを自動で付与しないため、ランダムなソルトの生成と設定が必要なことは注意が必要です。
