現在、特定の情報を暗号化し、AES/CBC/PKCS5Padding暗号化を使用して128ビット秘密鍵サーバーに送信します。AESで暗号化されたトークンを使用する脆弱性がありますか？
このトークン内では
サーバーは、秘密キーを使用してこの情報を暗号化し、クライアントに渡します。
クライアントは制限されたリソースを要求し、このトークンをサーバーに提示し、サーバーはそのトークンを復号し、内容を検証して制限されたリソースへのアクセスを提供します。
リソースの制限の可能性を避けるため、発行されたトークンに関する情報をサーバーに保存しないようにします。
私はセキュリティの専門家ではないため、潜在的な脆弱性を示す助けとなっていないか、またはこれがなぜ悪い考えであるのか非常に感謝しています。
比較のためハッシュバージョンを送信してください。
ハッシュ関数を使用するだけでは不十分です。ちょうど塩を追加するだけでセキュリティを向上させることはほとんどありません。代わりに、約100msの間、ランダムな塩でHMACを繰り返し、塩をハッシュで保存します。 PBKDF2（別名Rfc2898DeriveBytes）、password_hash/password_verify、Bcryptなどの関数を使用します。要点は、攻撃者が無差別にパスワードを見つけるのに多くの時間を費やすことです。ユーザーを保護することが重要です。安全なパスワード方法を使用してください。
ジム・フェントンによるToward Better Password Requirementsを参照してください。
[DRAFTは、NIST Special Publication 800-63Bデジタル認証ガイドライン]（ https://pages.nist.gov/800-63-3/sp800-63b.html）
NISTの新しいパスワードルール - あなたが知っておくべきこと：ソフォス
によって https://nakedsecurity.sophos.com/2016/08/18/nists-new-password-rules-what-you-need-to-know/
が代わりにパスワードをパスすることが必要ですバージョンのハッシュ？ハッシュバージョンでは、PBKDF2、password_hash、bcryptなどのHAMC反復関数を意味します。このキーは、管理者アクセス権を持つアタッカーだけが知っていることに注意してください。 – zaph
良い点私たちがパスワードを渡す唯一の理由は、最初の認証で使用された最初のパスワードハッシュと同じコードで送信することですが、それを見ていきます。 – BrendanM
代わりにトークンにハッシュを保持し、フィードバックのためにトークンを受け取ったらハッシュを直接比較するように変更しました。パスワードハッシュは、sha-512と64バイトのランダムな塩を使用して行われます。 – BrendanM