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 シークレットです。発行者と検証者が別の組織であれば、むしろ非対称方式が適しています。
見えません。見る手段が存在しません。このページはスタイルもスクリプトも埋め込んだ 1 枚の静的 HTML で、ブラウザに届いた後は何も読み込まず、何も送信しません。解析ツールもフォントも外部スクリプトもなく、記録を取りうるサーバーもありません。