問題タブ [salt]

SaltEnabledを設定すると、Microsoft Enterprise LibraryのHashProviderでソルトがどのように生成されますか？

新しいマシンにランダムですか？マジックナンバーですか？

（私はソルトとは何かを知っています。問題は、エンタープライズライブラリHashProviderのソルトの実際の値は何ですか）

ユーザーのパスワードをソルトおよびハッシュする場合は、ソルトがあれば明らかに役立ちます。塩の長さに関するベストプラクティスはありますか？ソルトをユーザーテーブルに保存するので、ストレージサイズとセキュリティの間の最良のトレードオフが必要です。ランダムな10文字の塩で十分ですか？それとももっと長いものが必要ですか？

私の Web アプリケーションはコンテナ管理のセキュリティに依存しています。私が知る限り、JDBC または DataSource Realm を構成するだけでダイジェストされたパスワードをデータベースに保存するのは簡単ですが、それらのダイジェストにソルトを追加する方法はありません。

助言がありますか？

編集：質問する前にもう少し考える必要があるようです;-)

誰がダイジェスト計算を行うか (クライアントまたはサーバー) を選択し、それに応じて Tomcat を構成するだけです。

パスワードソルトの「ソルト」という言葉に意味はありますか?

bCryptのjavadocには、パスワードを暗号化する方法に関する次のコードがあります。

プレーンテキストのパスワードが以前にハッシュされたものと一致するかどうかを確認するには、checkpwメソッドを使用します。

これらのコードスニペットは、ランダムに生成されたソルトが破棄されることを意味します。これは事実ですか、それともこれは単なる誤解を招くコードスニペットですか？

ランダムなソルト値を生成し、それをアプリケーション状態にしたいと考えています。

現在、私は Web ファームを使用しているため、アプリケーションの状態はマシンごとに異なります。分散型ファーム アプリも購入したくありません。

だから..これに対するいくつかの解決策は何ですか? コードまたは web.config ファイルでハードコーディングできると思っていましたが、それは eva の同じソルトを意味します..あまり安全ではありません。

誰にも提案はありますか？

覚えておいてください-私は、すべてのマシンで同じである一意のキー（GUIDなど）を求めています。多分設定ファイルが唯一の方法ですか？

クライアント側の JS でハッシュ化されたユーザー名とパスワード (http POST 経由で送信) を高次の時間値 (1 分未満の解像度) でソルトして、ユーザー名とパスワードのハッシュを定数値として送信することを回避します。許可されていないユーザー (つまりスニファー) による POST 偽造によるログイン試行に使用されます。

これにより、渡されたハッシュの有効期限が短くなります。

彼らが JS を調べて、今回のソルトが使用されていることを確認した場合、ソルトが何であるかを知っていれば、MD5 を破る作業はどれほど簡単になるでしょうか?

スティーブン

パスワードへのソルトの目的を理解するのに苦労しています。主な用途は、レインボー テーブル アタックを妨害することだと理解しています。ただし、これを実装するために私が見た方法は、問題を実際に難しくしているようには見えません。

ソルトを次のように使用することを提案する多くのチュートリアルを見てきました。

これは、ハッシュが元のパスワードではなく、パスワードとソルトの組み合わせにマップされるようになったためです。しかし、$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」が含まれていることが知られているため、salt の目的はわかりません。

誰もがこれに当てることができる光をありがとう。

編集：助けてくれてありがとう。私が理解していることを要約すると、ソルトはハッシュ化されたパスワードをより複雑にするため、事前に計算されたレインボー テーブルに存在する可能性がはるかに低くなります。私が以前誤解していたのは、すべてのハッシュに対してレインボー テーブルが存在すると想定していたことです。

6 文字の長さで、数字が 1 つ必要で、「煩わしい」と韻を踏まなければならないパスワードを要求するさまざまな Web サイトに遭遇したことはありませんか。

明らかに、これが必要な場合もあれば、すべてセキュリティのためである場合もあるレガシーな理由があります。私が持っている標準的なパスワードのセットは、これらの固有のルールと一致しないことが多いため、新しいパスワードを作成して覚えなければならないため、かなり面倒です。

ユーザーのパスワードがどれだけ複雑かを気にしているのであれば、セキュリティの観点からもっと重要なことがあるようです。誰かが実際にそのパスワードを手に入れることができた場合、明らかにより大きな問題を心配する必要があります. ユーザーが自分のセキュリティについて心配することに頼る前に、自分の役割を果たし、システムの最後をロックダウンしてください。

私の実際の質問は次のとおりです。これらの複雑なパスワード ルールに代わるものとして、ユーザーが複雑なことを覚えるという重荷を負わずに、レインボー テーブルやブルート フォース ハッシュ リバーサーのリスクを軽減する方法はありますか?

いくつかのアイデア：塩漬け、...