タグ付けされた質問 「salt」

データベースストレージのパスワードをハッシュするときは、常に適切なエントリごとのソルト文字列を使用しました。私のニーズのために、ソルトをハッシュされたパスワードの隣のDBに保存することは常にうまくいきました。 ただし、ソルトをデータベースとは別に保存することを推奨する人もいます。彼らの主張は、データベースが侵害された場合でも、攻撃者は特定のソルト文字列を考慮に入れてレインボーテーブルを作成し、一度に1つのアカウントをクラックすることができるというものです。このアカウントが管理者権限を持っている場合は、他のアカウントをクラックする必要はないかもしれません。 セキュリティの観点から、塩を別の場所に保管することは価値がありますか？サーバーコードとDBが同じマシン上にあるWebアプリケーションについて考えてみます。ソルトがそのマシンのフラットファイルに格納されている場合、データベースが危険にさらされている場合、ソルトファイルも同様に破損する可能性があります。 これに対する推奨される解決策はありますか？

250 security  authentication  hash  cryptography  salt 

パスワードへのソルトの目的を理解するのに問題があります。主な用途はレインボーテーブル攻撃を阻止することであることは私の理解です。ただし、これを実装するために私が見たメソッドは、問題を実際に難しくするようには見えません。 私はソルトを次のように使用することを示唆する多くのチュートリアルを見てきました： $hash = md5($salt.$password) その理由は、ハッシュが元のパスワードではなく、パスワードとソルトの組み合わせにマッピングされるようになったためです。しかし$salt=foo、$password=barそして、と言い$hash=3858f62230ac3c915f300c664312c63fます。今、レインボーテーブルを持つ誰かがハッシュを逆にして、入力 "foobar"を考え出すことができます。次に、パスワードのすべての組み合わせ（f、fo、foo、... oobar、obar、bar、ar、ar）を試すことができます。パスワードを取得するのにさらに数ミリ秒かかる場合がありますが、それ以外はそれほど多くありません。 私が見た他の用途は私のLinuxシステムです。/ etc / shadowには、ハッシュされたパスワードが実際にソルトとともに保存されます。たとえば、「foo」のソルトと「bar」のパスワードは、次のようにハッシュされます$1$foo$te5SBM.7C25fFDu6bIRbX1。ハッカーがなんとかしてこのファイルを入手できたとしても、のリバースハッシュにte5SBM.7C25fFDu6bIRbXは "foo"が含まれていることがわかっているため、ソルトの目的はわかりません。 誰もがこれに当てることができる光をありがとう。 編集：助けてくれてありがとう。私が理解していることを要約すると、ソルトはハッシュされたパスワードをより複雑にするため、事前に計算されたレインボーテーブルに存在する可能性がはるかに低くなります。以前私が誤解していたのは、すべてのハッシュにレインボーテーブルが存在すると想定していたことです。

220 hash  cryptography  salt  rainbowtable 

bCryptのjavadocには、パスワードを暗号化する方法に関する次のコードがあります。 String pw_hash = BCrypt.hashpw(plain_password, BCrypt.gensalt()); 平文のパスワードが以前にハッシュされたものと一致するかどうかを確認するには、checkpwメソッドを使用します。 if (BCrypt.checkpw(candidate_password, stored_hash)) System.out.println("It matches"); else System.out.println("It does not match"); これらのコードスニペットは、ランダムに生成されたソルトが破棄されることを私に示唆しています。これは事実ですか、それとも誤解を招くコードスニペットですか？

189 java  encryption  passwords  salt  bcrypt 

ユーザーパスワードのハッシュに関するDavidHaydenの記事の1つを読んでいました。 本当に私は彼が達成しようとしていることを得ることができません。 これが彼のコードです： private static string CreateSalt(int size) { //Generate a cryptographic random number. RNGCryptoServiceProvider rng = new RNGCryptoServiceProvider(); byte[] buff = new byte[size]; rng.GetBytes(buff); // Return a Base64 string representation of the random number. return Convert.ToBase64String(buff); } private static string CreatePasswordHash(string pwd, string salt) { string saltAndPwd = String.Concat(pwd, …

178 c#  hash  passwords  salt 

これは単純なMD5よりもはるかに安全ですか？パスワードのセキュリティについて調べ始めたところです。PHPは初めてです。 $salt = 'csdnfgksdgojnmfnb'; $password = md5($salt.$_POST['password']); $result = mysql_query("SELECT id FROM users WHERE username = '".mysql_real_escape_string($_POST['username'])."' AND password = '$password'"); if (mysql_num_rows($result) < 1) { /* Access denied */ echo "The username or password you entered is incorrect."; } else { $_SESSION['id'] = mysql_result($result, 0, 'id'); #header("Location: ./"); echo …

169 php  security  passwords  salt  password-hash 

私はいつも好奇心旺盛でした...ハッシュのためにパスワードをソルトするときにどちらが良いですか：プレフィックス、またはポストフィックス？どうして？それとも、塩漬けであれば問題ありませんか？ 説明するには：データベースに保存するためにパスワードをハッシュする前に、パスワードをソルトする必要があることを（願わくば）わかっているはずです[ 編集：最近Jeff Atwoodで起こったことなどを避けることができます]。通常、これはソルトをパスワードと連結してから、ハッシュアルゴリズムに渡すことによって行われます。しかし、例は異なります...一部の例は、パスワードの前にソルトを付加します。一部の例では、パスワードの後にソルトを追加しています。塩を真ん中に入れようとする人も見ました。 それで、どちらがより良い方法で、なぜですか？ハッシュの衝突の可能性を減らす方法はありますか？私のグーグルは、そのテーマに関してまともな分析をしていません。 編集：すばらしい回答者の皆さん！一つだけ答えてすみませんでした。:)

162 hash  cryptography  passwords  salt 

私が行っていることは、実際にはパスワードをソルト処理するのではなく、それらをペパーリングすることであることがわかったディスカッションに出会い、それ以来、次のような関数で両方を実行し始めました。 hash_function($salt.hash_function($pepper.$password)) [multiple iterations] 選択したハッシュアルゴリズムを無視します（これはソルト＆ペッパーの説明であり、特定のアルゴリズムではありませんが、安全なアルゴリズムを使用しています）、これは安全なオプションですか、それとも何か別のことをする必要がありますか？用語に不慣れな方のために： 塩は、通常、それが不可能なパスワードをクラックするハッシュテーブルを使用するようにするために設計されたデータベース内の文字列を格納し、ランダムに生成された値です。各パスワードには独自のソルトがあるため、パスワードを解読するためにすべて個別にブルートフォースする必要があります。ただし、ソルトはパスワードハッシュとともにデータベースに格納されるため、データベースのセキュリティが侵害されると、両方が失われます。 唐辛子は秘密であることが意図されている（通常は、アプリケーションのソースコードにハードコードされた）データベースとは別に格納されているサイト全体の静的な値です。これは、データベースが侵害されてもアプリケーション全体のパスワードテーブルがブルートフォース可能にならないようにするために使用されます。 不足しているものはありますか？ユーザーのセキュリティを保護するために、パスワードをソルト＆ペッパーリングするのが最良のオプションですか？この方法で行うことには、潜在的なセキュリティ上の欠陥はありますか？ 注：説明のために、アプリケーションとデータベースは別々のマシンに格納されていると仮定します。パスワードは共有しないでください。したがって、データベースサーバーの違反が、アプリケーションサーバーの違反を自動的に意味するわけではありません。

145 security  hash  passwords  salt  password-hash 

休業。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善してみませんか？この投稿を編集して、事実と引用で回答できるように質問を更新してください。 2年前休業。 この質問を改善する どれ塩塩漬けし、ユーザーのパスワードをハッシュするとき、すべてのは明らかに役立ちます。塩分の長さに関するベストプラクティスはありますか？私は自分のユーザーテーブルにソルトを格納するので、ストレージサイズとセキュリティの間の最良のトレードオフが必要です。ランダムな10文字のソルトで十分ですか？それとももっと長いものが必要ですか？

127 encryption  hash  salt 

このコードは、パスワードをソルトでハッシュすることになっています。ソルトとハッシュ化されたパスワードはデータベースに保存されています。パスワード自体はそうではありません。 操作のデリケートな性質を考慮して、私はすべてがコーシャであることを確認したかった。 import hashlib import base64 import uuid password = 'test_password' salt = base64.urlsafe_b64encode(uuid.uuid4().bytes) t_sha = hashlib.sha512() t_sha.update(password+salt) hashed_password = base64.urlsafe_b64encode(t_sha.digest())

97 python  authentication  hash  passwords  salt 

最近、インターネットで見つけたログインスクリプトに独自のセキュリティを実装しようとしています。ユーザーごとにソルトを生成するための独自のスクリプトを作成する方法を学ぶのに苦労した後、私はに遭遇しましたpassword_hash。 私が理解していることから（このページの読みに基づいて）、を使用すると、ソルトはすでに行に生成されていますpassword_hash。これは本当ですか？ 私が持っていたもう一つの質問は、2つの塩を持っているのは賢明ではないかということでした。1つはファイルに直接、もう1つはDBにありますか？そうすれば、誰かがDB内のソルトを危険にさらした場合でも、ファイルに直接ソルトがありますか？私はここで塩を保存することは決して賢い考えではないことを読みました、しかしそれは人々がそれによって何を意味するかをいつも私に混乱させました。

94 php  salt  password-hash  php-password-hash 

更新：ソルトとは何か、レインボーテーブルとは何か、辞書攻撃とは何か、ソルトの目的は何かを尋ねていないことに注意してください。私は質問しています：ユーザーのソルトとハッシュを知っているなら、彼らのパスワードを計算するのはとても簡単ではありませんか？ 私はプロセスを理解しており、いくつかのプロジェクトで自分で実装しています。 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 -------------- …

85 security  hash  salt  dictionary-attack