署名鍵がJWTで盗まれるのを怖がらないのはなぜですか？
クライアントにセッションIDのみが保存される可能性がある従来のセッションシステムでは、暗号化さえされている場合、ユーザーは、データベースまたはセッションストアに直接アクセスしないと、別のユーザーのIDを引き継いだり、権限を昇格したりできません。
しかし、JWTを使用すると、攻撃者が秘密署名鍵を手に入れると、多大な損害を与える可能性があります。 JWTにユーザーIDを格納する場合、単純に任意のユーザーのトークンに署名し、ユーザーに代わって行動することはできませんか？これと対照的に、MITM攻撃を許可するSSL証明書の盗難は、これはほぼ1桁悪いように見えます。トラフィックを盗聴したり、リクエストを変更したりする必要はなく、必要なユーザーを選択するだけで、システムに完全に検出されずにアクセスできます。
私は秘密鍵が秘密であることを意図していることを理解しています。SSH鍵を紛失して攻撃者が私のSSH鍵を乗っ取れば、攻撃者は何でも好きなことをすることができます。しかしIIRCでは、SSL証明書（またはHeartbleedなど）が漏洩する多くの事例がありましたが、少なくともユーザーが直接任意のIDを引き継ぐことはできません。 JWTでは、すべてを1つのバスケットに入れているように見え、何も起こりません。
これは本当にセキュリティ上の問題ですか？ JWTを完全に使用しない以外に、問題を軽減する方法はありますか？それとも何か不足していますか？
サービス間でクレーム付きのトークンを渡すというアイデアは本当に気に入っていますが、同時に、会社のすべてのプライベートデータを暗号化し、redditに公に投稿して考えるのと少し似ています私は彼らが壊れないことを願っています暗号化。
あなたは単一の投稿内で実際に複数の質問をします：
- 秘密鍵への不正アクセスに関連するリスク
- さまざまなプロセスが混在している：メッセージ/承認の署名（JWT内）と通信チャネル（SSL）の保護
- 暗号化強度への信頼
署名と秘密鍵：もちろんリスクがあります。これには業界全体があり、標準、慣行などがあります。それに関連するすべてのものに名前を付けることはできません。リスクを軽減するには？繰り返しますが、広すぎる質問です。いくつかのランダムなヒント：ハードウェアへの人の物理的なアクセスを制限する、「知る必要がある」原則、アクセス制御と定期的なレビュー、ID管理、監査、階層化セキュリティ、JWT署名鍵の有効期限の短い証明書。 1ヶ月、そして彼らのCAチェーンは長生きします。
暗号化の強度（引用：暗号化が破られないことを願います）：もちろん、を除いて1回pad完全な暗号化はありません。ここではなく、別のサイト Cryptography SE で信頼性について質問することをお勧めします。連中は、なぜAES、RSA、ECCに依存できるのか、そしてそのための条件（特定の操作モード、ランダム性の役割）、リスクは何かについて説明します。