タグ付けされた質問 「dictionary-attack」

11
なぜ塩は辞書攻撃を「不可能」にするのですか?
更新:ソルトとは何か、レインボーテーブルとは何か、辞書攻撃とは何か、ソルトの目的は何かを尋ねていないことに注意してください。私は質問しています:ユーザーのソルトとハッシュを知っているなら、彼らのパスワードを計算するのはとても簡単ではありませんか? 私はプロセスを理解しており、いくつかのプロジェクトで自分で実装しています。 s = random salt storedPassword = sha1(password + s) 保存するデータベース: username | hashed_password | salt 私が見たソルティングのすべての実装は、パスワードの最後または最初にソルトを追加します。 hashed_Password = sha1(s + password ) hashed_Password = sha1(password + s) したがって、彼の塩の価値があるハッカーからの辞書攻撃(ha ha)は、上記の一般的な組み合わせで保存されている塩に対して各キーワードを実行するだけです。 確かに、上記の実装は、根本的な問題を実際に解決することなく、ハッカーに別のステップを追加するだけですか?この問題を回避するための代替手段はありますか、それとも私は問題を誤解していますか? 私が考えることができる唯一のことは、ソルトとパスワードをランダムなパターンで組み合わせたり、他のユーザーフィールドをハッシュプロセスに追加したりする秘密のブレンドアルゴリズムを使用することです。実りあることを証明するための辞書攻撃のためにそれらを。(コメントで指摘されているように、更新します。ハッカーがすべての情報にアクセスできると想定するのが最善であるため、これはおそらく最善ではありません)。 ハッカーがパスワードとハッシュのリストを使用してユーザーデータベースをハッキングすることを提案する方法の例を挙げましょう。 ハッキングされたデータベースのデータ: RawPassword (not stored) | Hashed | Salt -------------------------------------------------------- letmein WEFLS... WEFOJFOFO... 一般的なパスワード辞書: Common Password -------------- …
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.