問題タブ [salt]

ソルト パスワード ハッシュについて読んだ後、Im はサイト Im の構築に管理領域の単純なバージョンを実装したいと考えています。

このアイデアをうまく​​実装したコードとのリンクがあれば、共有していただければ幸いです。

ありがとう、

PHP/MySQL のソルトされたパスワードに関する以前の質問に加えて、ソルトに関する別の質問があります。

パスワードの前後に「ランダムなソルトを使用する」と誰かが言った場合、これは次のことを意味しますか?

• 1 回ランダムに生成された静的な文字列を作成する、または
• パスワードが作成されるたびにランダムに変化する文字列を作成しますか?

ソルトがすべてのユーザーに対してランダムであり、ハッシュされたパスワードとともに保存されている場合、元のソルトを検証のために取得するにはどうすればよいでしょうか?

重複の可能性:
ユーザーパスワードソルトの最適な長さは?

Stack Overflow でこの質問に対する答えを見つけようとしましたが、成功しませんでした。

SHA-1 ハッシュ (つまり 160 ビット) を使用してパスワードを保存し、アプリケーションには SHA-1 で十分であると仮定します。生成されたパスワードのハッシュにソルトを使用する期間はどれくらいですか?

私が見つけた唯一の答えは、論理的に聞こえるハッシュ自体 (この場合は 160 ビット) よりも長くしても意味がないということでしたが、それほど長くする必要がありますか? たとえば、Ubuntu は SHA-512 で 8 バイトのソルトを使用します (私は推測します)。したがって、SHA-1 にも 8 バイトで十分でしょうか、それとも多すぎるでしょうか?

学習プロジェクトとして、PHP でログイン スクリプトをまとめようとしています。

これは、ユーザー登録時にデータベースに書き込むためのコードです。これらの値は両方ともデータベースに書き込まれます。

ログインすると、次の関数が起動されます。

残念ながら、私のコードをステップ実行すると、2 つの値が等しくなることはありません。誰かが理由を理解するのを手伝ってくれますか?

Textbox.Text からパスワードを簡単にソルトするにはどうすればよいですか?

.NET フレームワークに組み込みのウ​​ィザードリィはありますか?

ハッシュとソルトを行っているフィールドが1行にあります。各行の塩は異なります。各行にさらにいくつかのフィールドをハッシュ/ソルトすることにしました。

同じ行の新しいフィールドに同じソルトを使用すると、フィールドごとに新しいソルトを生成する場合と比較して、データがレインボー攻撃を受けやすくなりますか？私の論理では、同じソルトを使用するのは同じ行の2、3のフィールドだけであり、キー/ソルトの管理がはるかに簡単になります。

我慢してください、私はほんの数週間しかPHPを学んでいないので、サンプルコードは私を混乱させるかもしれません。やっと塩漬けがわかったと思います！侵害された場合、データベース内のパスワードを保護するためです。

私が理解していないのは、ハッカーがユーザーのパスワードを理解しようとしている場合、なぜハッカーはハッシュをクラックしなければならないのでしょうか（それが彼らの目標であると仮定して）？これは簡単ではないでしょうか？パスワード推測からの唯一の防御策は、パスワード入力の制限を1日にX回またはCAPTCHAで実装することですか？

そもそもデータベースはどのようにハッキングされるのでしょうか？それはより多くのパスワード推測ですか、それともMySQLインジェクションを通じてハッシュを取得できますか？

ありがとう！

ほとんどのユーザーと同様に、私は単にパスワードを安全に保存する方法を見つけようとしています。ここで見つけられなかった (あるいは私の理解不足かもしれません) のは、データベース内のソルト付きハッシュを取得し、ソルトをハッシュされたパスワードから分離する方法です。特に、ソルト + パスワードを単一の列。

パスワードを暗号化するこれらすべてのクールな方法 (SHA-256、しかし MySQL は SHA/1 と MD5 のみをサポートしていますか?) などを PHP マニュアルから見つけていますが、パスワードを保存および取得する方法がわかりません。

だから、これは私が理解しているすべてです：

その後は塩で迷子。

ソルトなしでパスワードを取得するのは簡単ですが、ソルトは私を混乱させます。特に一意で安全な場合、$salt から値を取得するにはどうすればよいですか? それらを別のデータベースに隠しますか? 定数 (安全ではないようです)?

編集: HMAC のキー変数はソルトであるはずですか、それとも他のものですか?

CodeIgniter を使用して Web サイトのログイン ライブラリを開発しています。認証コードは次のとおりです。

成功、失敗、または禁止を示す戻り値。各ユーザーには、データベースに格納された一意のソルトがあります。

もともと私はデータベースからソルトを取得し、ユーザーが入力したパスワードとPHPのデータベースからソルトを組み合わせてから、組み合わせた値でデータベースに再度クエリを実行しました。これにより、データベースへのアクセスが 1 回だけで済み、コードも少なくて済むため、速度が向上すると考えました。私はそれも同様に安全だと思っていましたが、この質問に対するトップの回答を読んだ後 PHP と MySQL でハッシュをソルティング...

まず、DBMS (MySQL) が暗号化ハッシュをサポートする必要はありません。これらはすべて PHP 側で行うことができます。また、それを行う必要があります。

...見落としていたセキュリティ上の問題があるのではないかと考え始めました。

このコードには実際に何か問題がありますか?

名前とともにランダムな文字列を保存する代わりに、パスワードをソルトする手段としてユーザー名を使用することについて議論しています。私の正当な理由は、ソルトの目的はレインボー テーブルを防ぐことであるということです。では、これがそこにある別のデータ セットよりも現実的に安全性が低いのはなぜでしょうか?

例えば、

hash( md5(johnny_381@example.com), p4ss\/\/0rD)

対

hash( md5(some_UUID_value), p4ss\/\/0rD)

ユーザー名だけに固執して物事を単純化できなかった本当の理由はありますか? 私の Web 検索の結果は、salt をパスワードのようにする方法についての議論だけでしたが、その背後に何の理由もなく終了しました。 100万年の範囲に入ることなく、それに立ち向かいます。現実の処理の限界について考えると、人々がハッシュを知っていて、パスワードをまだ知らず、個々のハッシュをブルート フォースするためにスーパー コンピューターの範囲に移動した場合、これは大したことではないと思います。

誰かがここで私を啓発してもらえますか?