AES自体でパスワードを暗号化することは、SHA1よりも安全ですか？
これは実際には実用的な問題ではなく、好奇心の問題です。 CSの教授が、パスワードのmd5からSHA1ではなくAESにステップアップすることをすすめたそうです。これが実際に多かれ少なかれ安全であるかどうかについて誰かが洞察を持っていますか？
問題についてのいくつかの考え：
- SHA1は一方向なので、データを保存する機能よりも安全です。
- 一方、ハッカーはパスワードをまだ知らないため、AESの解読可能な性質を利用できない可能性があります。
- 彼がそれを推測しない限り。しかし、その後、私がそれをどのように暗号化したとしても、彼は存在するでしょう。
- 解読キーが出力と一致すると、AESのパスワードが解読されることがわかっているため、ハッカーのコンピューターでブルートフォース攻撃を受ける可能性があります。
- しかし、ハッカーはそれがどのように暗号化されているかを知らないので、彼はそれを試みません。
- しかし、ハッカーが暗号化コードを入手した可能性もあります。その場合、それは、どのデータがブルートフォースに時間がかかるかという問題です。
- ほとんどのWebサイトはmd5またはsha1（正しい？）を使用しているため、これらのハッシュのルックアップテーブルは、AESメソッドよりもはるかに広く普及しています。したがって、AESメソッドをより安全にします。
- しかし、両方のメソッドをソルト化すると、ルックアップテーブルの影響を等しく受けなくなります。
回答のいくつかの一般的なポイント、およびカウンターポイント：
AES暗号化は衝突に強いようには設計されていないため、同じハッシュ文字列の長さで衝突が増える可能性があります。
より長いソルトを使用している場合、暗号化されたパスワードはSHA1ハッシュよりも長くなります。これは、衝突を同等のレベルに下げるのに十分かもしれません-あるいはそうでないかもしれません。
AES暗号化により、パスワードの長さが16バイト以内でわかります。
AESメソッドに追加することができます。暗号化した後、適切な長さまでパディングまたはトリミングします（これは、衝突を避けるためにSHA1よりも長くなります）。
短い答え：悪い考え、それをしないでください。
より長い答え：演習のポイントは、サーバーが指定された検証を可能にする何かを格納することですパスワード。ただし、パスワードのrebuildは許可されません。後者の特性が望ましいため、攻撃者によるサーバーデータベースへの不正な読み取りアクセスの影響は制限されたままです。
したがって、与えられたパスワードを検証値に変換する一方向の決定論的変換が必要です。変換は次のとおりです。
- 辞書の攻撃を阻止するために、構成可能に遅くなります。
- 事前計算されたテーブルを含む並列ディクショナリ攻撃を防ぐために、すべてのインスタンスで区別されます（これはソルトの目的です）.
MD5またはSHA-1の1回の呼び出しは両方のアカウントで失敗します。これらの関数は非常に高速で、ソルト化されていないためです。スローネスは多くの呼び出し（数千、場合によっては数百万）をネストすることで実行でき、ソルトは「どこかに」注入できますが、その方法には良い方法と悪い方法があります。 PBKDF2 は、それを行う標準の変換であり、悪くはありません（ただし、 bcryptの方が望ましい ）。
ただし、MD5とSHA-1は少なくとも1つのことを正しく行います。つまり、一方向であるように設計されています。それは難しいです。一方向関数が実際に存在できることは理論的にも証明されていません。現在、世界中の暗号技術者が competition に関与しており、新しいより優れた一方向ハッシュ関数を設計しています。
したがって、教授が推奨しているように見えるのは、一方向性のために設計された関数を、一方向性のために設計されたではない関数で置き換えることです。速度低下とソルティングについては何も修正しませんが、MD5とSHA-1の1つの良い点を取り除きます。さらに、AESは関連キー攻撃に関して 比較的弱い であることが知られています-意図された目的、つまり暗号化にAESが使用されている限り、これは問題ではありませんが、重要になります一方向ハッシュ関数の構成要素に変換されると問題が発生します。 AESデザインの一部を再利用して安全なハッシュ関数を構築することは可能と思われますが、かなりのやり直しが必要です（たとえば Whirlpool および [〜＃〜] echo [〜＃〜]を参照） ）。
したがって、自家製のAESベースのパスワードハッシュ方式を使用しないでください。さらに言えば、「自家製」のものは使用しないでください。これは災害のレシピです。セキュリティはテストできません。安全なアルゴリズムを作成する唯一の既知の方法は、何百人もの訓練された暗号学者に数年間それを注意深く見させることです。一人ではできません。一人の暗号学者でさえそれを危険にさらすことはありません。
代わりに、bcryptを使用してください。 PBKDF2も悪くありません。
ほとんどのWebサイトはmd5またはsha1（正しい？）を使用していたので、これはハッカーが予期することです。したがって、AESメソッドをより安全にします。
ほとんどのウェブサイトがMD5またはSHA1を使用している場合でも、AESに切り替える通常はそこでは使用されないという理由でそれはそれ以上安全ではありません-それだけです obcursityによるセキュリティ 、これは通常、セキュリティの向上に効果的に貢献しません。優れたアルゴリズムを使用して（所与の目的のために十分にテストされている）、それを公に文書化する方が、優れているかどうかを確認できず、自分がそれを使用します。
現時点では、AESまたはこのような他の暗号化アルゴリズムを使用するときに、次のような欠点が考えられます。
- 暗号化アルゴリズムは通常、衝突を回避するように設計されていません。以下のコメントで指摘されているように、ブロック暗号の予想される疑似ランダム動作のため、問題にならない可能性があります。しかし、それでも、設計されていないものに暗号化アルゴリズムを使用しています。
- 暗号化アルゴリズムへの攻撃があり、クリアテキストとパスワードが実際には同じであることを知っていれば、はるかに簡単に実行できると考えられます（使用しているアルゴリズムについての事実が何らかの形でリークしている可能性があります）。それは例えばここで議論されていること）。
- 暗号化アルゴリズムが生成するデータは、多くの場合、クリアテキストの長さによって異なります。つまり、暗号文はパスワードの長さに関する情報を保持します。 AESの場合、これは 私の知る限り16バイトの倍数 ;です。一方、ハッシュ値は固定サイズ（SHA1の場合は160ビット/ 20バイトなど）です。つまり、潜在的なハッカーは、ハッシュ値からよりも暗号化されたテキストからより多くの情報を入手する可能性があります。
- 暗号化では、十分にテストされてコミュニティですでに長期間使用されているもの（徹底的に検査する時間があったことを意味します）を使用するよりも、通常は常に安全性が低く、自分で何かを調理します（その後、おそらく自分だけが使用します）。多くの暗号解読者による）。
- パスワードハッシュアルゴリズムが低速であることを確認し、潜在的な攻撃者がシステムへの総当たり攻撃を妨害するようにします。これを実現する1つの方法は、たとえば、PKBDF2のように、複数のラウンドでハッシュを繰り返し実行することです。詳細については、 http://security.blogoverflow.com/2013/09/about-secure-password-hashing/ を参照してください
このアプローチで私が目にする1つの直接的な問題は、AESの固定キー長です。 AES-128を使用すると、パスワードの16バイトに制限されます。長いパスワード、または長いパスフレーズはどうですか？
パスワードの長さに対応するには、ハッシュ関数が必要になるため、最初のポイントに戻ります。
ブロック暗号をハッシュ関数に変換する、よく研究された安全な方法があります。Davies-Meyer、Matyas-Meyer-Oseas、Miyaguchi-PreneelなどのPGVモードと呼ばれます。
（*）「セキュア」の適切な定義。
ただし、次の点を考慮してください。
私はあなたのサイトに侵入し、システムにAESキーが構成されていることに気づくのに十分なアクセス権を取得します。「暗号化」されているように見えるのはあなたのパスワードだけです...私がやろうとしていることを推測します。
私はそれらをハッシュ化したままにし、パスワードデータベース全体を簡単にスクレイピングする余地を大幅に減らします。
その上、サイトの所有者として、最初からユーザーのパスワードを解読する機能は望んでいません。それ以外の場合は、「パスワードを回復する」オプションが上級管理者が要求できる機能になり、技術的には基盤となるシステムはハッシュシステムではなく暗号化システムを使用して構築されているため、これを行うことができます（不完全な理由ですが、ソフトウェア開発者はこのような要求を処理します）。
主に：セキュリティが懸念される場合は、奇抜で奇抜なことを行わないでください。アルゴリズムに取り組んでいるチームのチームが大量の調査を行うことができないため、巨大なセキュリティホールを作成する可能性があります。特定の目的のために。
正解は次のとおりです。まったく問題ではありません。
パスワードの場合、唯一の実用的な攻撃は、ブルートフォースで正しいパスワードが見つかるまで、パスワードのリストを試すことです。それを行うためにSHA1やAESを直接攻撃しようとする人はいません。現在の調査時点でさえ、SHA1への攻撃はAESの1万倍も簡単です。どちらも完全に不可能です（ここでは衝突は問題にならないため、パスワードハッシュを元に戻すためです）。そして、研究者が他のアルゴリズムを攻撃する別の方法を見つけると、オッズは来年逆転するかもしれません。
重要なのは、ハッシュの導出/パスワードの暗号化の速度です。しかし、例えばSHA1はより高速であり、（ブルートフォース攻撃を防ぐために）より低速にしたい場合は、複数回ハッシュすることができます。
ハッカーが「期待する」ことはそれほど関連性がなく、何かを「予期しない」ものにすることは単にあいまいです。 「すべてのパスワード文字を逆にすると、より安全になります」と言うようなものです。それはありません。ハッカーがパスワードデータベースにアクセスできる場合、ハッカーがパスワードハッシュ導出関数にアクセスできないことをどのように確認できますか？
「パスワードをそれ自体で暗号化する」際の1つの欠点：暗号化テキストの長さが攻撃者にパスワードの長さについての手掛かりを与える可能性があります。それはひどい。
いずれの場合も、できればユーザーに固有の何かでパスワードをソルトする必要があります。
ブロック暗号から構成されたMAC（メッセージ認証コード）があります。最もよく知られているのはおそらく CBC-MAC です。ハッシュマックと比べて、特に問題があります：
安全なブロック暗号を考えると、CBC-MACは固定長メッセージに対して安全です。ただし、それ自体では、可変長メッセージに対して安全ではありません。正しいメッセージタグ（つまり、CBC-MAC）のペア（m、t）と（m '、t'）を知っている攻撃者は、CBC-MACもt 'になる3番目のメッセージm' 'を生成できます。
[...]
この問題は、メッセージサイズのブロックを追加しても解決できません（たとえば、Merkle-Damgård強化を使用）。したがって、可変長メッセージの整合性を保護するために、CMACなどの別の操作モードを使用することをお勧めします。
より短い答え：ブロック暗号から構築されたMACのセキュリティは、それを構築する方法に依存します。単純な構造には、ほぼ間違いなく重大な欠陥があります。
珍しいアルゴリズムを設計したという事実はそれを安全にしません。 「自作」アルゴリズムは危険です。なぜなら、誰もそれらの暗号分析を行っていないからです。
@Thomas Porninが上に書いたように、AESは衝突耐性を持つようには設計されていません。さらに、AESは比較的高速であり、攻撃を単純化します。
SHA1は、衝突に強いように設計されていますが、SHA1は、大量のデータまたはファイルのハッシュを短時間で生成することを目的としているため、非常に高速になるように設計されています。その目的は、ハッシュされたパスワードへの攻撃を防ぐことではありません。
さまざまな種類の攻撃に耐性のあるパスワードハッシュを生成する場合は、パスワードストレッチを検討してください。テクノロジースタックと利用可能なライブラリに応じて、bcrypt、scrypt、argon2を検討してください。