0 ビットのエントロピー
鍵長
エンコード
HS256・HS384・HS512 用の HMAC 署名鍵をブラウザ内で生成。
スペース キーで再生成、C キーでコピー。シークレットは端末上の crypto.getRandomValues で生成します。
HS256・HS384・HS512 で署名されたトークンは、署名に使ったものと同じシークレットで検証されます。これはパスワードではありません。誰も入力せず、誰も覚える必要がなく、読み上げられる必要もありません。環境変数やシークレットマネージャーに置かれるランダムなバイト列であり、その役目は推測不可能であることだけです。
ここでのバイト列はブラウザの暗号論的擬似乱数生成器である crypto.getRandomValues から直接取得し、16進数または Base64 として出力しています。タイムスタンプもカウンターも Math.random も経路上に一切ありません。256ビットを選べば 32 バイト、384ビットなら 48 バイト、512ビットなら 64 バイト —— 長さはアルゴリズムが使うハッシュに対応します。
この値はブラウザ内で生成・保持されます。再読み込みすると値は消えます。
署名に使うアルゴリズムのハッシュ出力と同じ長さ以上です。HS256 なら 32 バイト（256ビット）、HS384 なら 48 バイト、HS512 なら 64 バイト。HMAC はブロック長を超える鍵をハッシュして縮めるため、200 バイトにしても 64 バイトより実質的に強くはなりません。危険なのは、これより短くすることです。
同じです。同一のランダムバイト列の書き方が違うだけで、32 バイトは 16進数で 64 文字、Base64 なら約 44 文字、強度は変わりません。ライブラリが期待する形式を選んでください。設定ファイルやシェルスクリプトを経由するなら、0-9 と a-f しか含まない16進数のほうが安全です。
Base64URL は + と / を - と _ に置き換え、パディングを省くため、URL やクエリ文字列、ファイル名にそのまま入れてもエスケープが要りません。それ以外の場面では標準の Base64 で十分です。JWT 自体は Base64URL でエンコードされますが、それはトークンの話であり、署名に使うシークレットの話ではありません。
使えますが、HMAC 署名が破られる最も一般的な原因がこれです。覚えやすい文字列が持つエントロピーは、その長さから受ける印象よりはるかに低くなります。有効なトークンを一つ手に入れた攻撃者は、ハードウェアの限界速度で候補をオフラインで試せます。回数制限は何の助けにもなりません。ランダムなバイト列を使ってください。
環境変数、あるいはシークレットマネージャーがあればそちらへ。リポジトリには絶対に置かないでください。git にコミットされたシークレットは、後から削除しても履歴に残り、履歴はクローンされ、フォークされ、バックアップされます。一度コミットしてしまった場合、確実な対処は交換することだけです。
実際に守れる周期で、そして漏洩が疑われた時点で直ちに。現実的な障害は、更新すると旧シークレットで署名した全トークンが無効になることです。ログアウトさせずに切り替えたいシステムでは、移行期間中は二つを併用するのが一般的です —— 署名は新しい鍵で行い、検証は新旧どちらも受け付け、その後に旧鍵を廃止します。
使えません。これらは非対称方式で、秘密鍵で署名し対応する公開鍵で検証するため、必要なのは共有シークレットではなく鍵ペアです。このページが生成するのは HS 系が使う対称鍵の HMAC シークレットです。発行者と検証者が別の組織であれば、むしろ非対称方式が適しています。