トークン & API キージェネレーター

エントロピー 122 ビット · ブラウザ内で生成、サーバーには送信されません

なぜ Math.random() を使わないのか？

Math.random() は疑似乱数ジェネレーターであり、その出力は予測可能でセキュリティトークンには不適切です。このツールは crypto.getRandomValues() を使用しており、TLS や SSH キー生成を支えるのと同じ API です。

トークンタイプの説明

UUID v4 はデータベース ID や相関トークンの標準です。Hex 文字列はセッショントークンやノンスに適しています。Base64 は API トークンにコンパクトです。プレフィックス付きの API キー（sk_ や vlt_ など）を使うと、漏洩した認証情報を識別してローテーションしやすくなります。

トークンはどのくらいの長さにすべきか

アクセスを保護するものであれば 128 ビットのエントロピーが下限であり、これは NIST SP 800-63B がランダム生成されたシークレットに求める水準です。Hex なら 32 文字、Base64 なら 22 文字、あるいは UUID v4 が 1 つ分に相当します。256 ビットを超えてもブルートフォース耐性は増えず、ログ量とヘッダーサイズが増えるだけです。文字種より長さが重要で、32 文字の Hex トークンと 22 文字の Base64 トークンは推測しにくさが同じです。

ベアラートークン、アクセストークン、API キー

これらの名前は認証情報の「使われ方」を表すもので、生成方法の違いではありません。ベアラートークンは提示するだけでアクセスが認められるトークンで、だからこそ HTTP の Authorization ヘッダーはそれをそのまま運びます。アクセストークンは有効期間が短いベアラートークンで、通常は OAuth フローで発行されます。API キーは人ではなくサービスに対して発行される長寿命のベアラートークンです。生成時点ではこの 3 つはすべて同じもの、すなわち不透明で高エントロピーなランダム文字列です。前の 2 つには Hex か Base64 を、スキャン可能なプレフィックスが欲しいときは API キーモードを使ってください。

API キーにプレフィックスを付ける理由

GitHub、Stripe、OpenAI、Slack がキーにプレフィックス（ghp_、sk_live_、xoxb_）を付けているのには理由があります。シークレットスキャナーが前後の文脈なしに、文字列だけで漏洩したキーを認識できるからです。プレフィックス付きのキーを公開リポジトリに push すれば、発行元は数分以内に失効させられます。素の 32 文字の Hex 文字列はコミットハッシュと見分けがつかないため、何にも検知されません。プレフィックスは環境も一目で分かるようにしてくれます。本番用のキーをステージングの設定に貼り付けてしまう事故に対する、最も安価な防御策です。