GitHubの認証トークンのフォーマットが変わります
はじめに
GitHubの認証トークンのフォーマットが、Secret Scanに引っかかりやすいように変更されます。
認証トークンをリセットし、この新しいフォーマットの恩恵にあずかりましょう。
Secret Scanとは
認証トークンをソースコードにハードコーディング(プログラムに直書きすること)してしまい、それをGitHubにコミットしてしまうと、
GitHub上のソースコードを読み、認証トークンを奪取し、それを使用すると秘密の情報にアクセスできてしまう
という事件に発展します。
Secret ScanとはGitHubがリポジトリをスキャンし、認証トークンがハードコーディングされていないか探し回り、もし見つかれば所有者に通報してくれるというサービスです。とても良いサービスですね。
問題は、認証トークンであると認識できるか、にあります。
認証トークンがSHAなどのハッシュ値と区別がつかない形式だと誤検知につながることは容易に想像できますね。そのため認証トークンであると高確率で認識できるようフォーマットを変更したというのが本記事の内容となります。
認証トークンフォーマットの変更内容
では認証トークンのフォーマットがどのように変わるか見ていきましょう。
1. 認証トークンには以下のプリフィックス(接頭辞)があります。これは今まで通りです。
ghp for GitHub personal access tokens
gho for OAuth access tokens
ghu for GitHub user-to-server tokens
ghs for GitHub server-to-server tokens
ghr for refresh tokens
2. プリフィックスに “_” (アンダースコア、アンスコ)をつけます。
ghp_xxx ってことです。アンスコはBase64には含まれないため、ハッシュ値をBase64にする通常のやり方であればハッシュ値と認証トークンを区別できることになります。これだけでSecret Scanの誤検知率が0.5%まで下がると見込んでいるそうです。エレガントな解法ですね！
3. CheckSum(チェックサム)をつけます。
認証トークンの下6桁に32ビットのchecksum(CRC32)を入れます。
チェックサムの計算が合えば認証トークンであるってことです！
4. entropy(エントロピー)も増やします。
上記対策でアンスコつけたりchecksumをつけたりすると、認証トークンのエントロピーが下がってしまいます。余計なものが付きますからね。
しかし新フォーマットでは認証トークンに使う文字を以下のように増やし、逆にエントロピーを増やしてしまいます！
旧： a-f, 0-9 (a-fはaからf、すなわちa, b, c, d, e, f を表します)
新： a-z, A-Z, 0-9
結論
とても良い対策ですね。
本件とは関係がないですが、GitHubの設定に不備(*)があり、本来秘密にしていたリポジトリが公開状態になった以下事例があります。クラウドサービスの設定不備で機密情報がダダ漏れだったというインシデントは結構あります。注意しましょう。
(*) ID/PASSをデフォルトのadmin/adminで使用していたというものです。
参考
この記事のもとです。
Secret Scanについての元の説明文です。