問題タブ [salt]

私はこれを調査しようとしましたが、まだ答えられていないいくつかの質問がありました。私は、8文字のパスワードがどのようにして高ビットの暗号化キーに変換されるかを調べていました。私の研究中に、塩の価値について話す記事を見つけました。

256文字すべてを使用できると仮定すると、8文字のパスワードは64ビット長になります。したがって、残りの64ビットは単なるソルト値です。そして、私が間違っている場合は訂正してください。ただし、これは、誰かがすべての可能な値（ブルートフォース）を試行しようとした場合、ソルトも不明であるため、すべての128ビットを試行する必要があるようにするためです。

私の質問は本当にこの「塩」の値に関連しています：

1. 誰かがアプリケーションを作成するとき、ソルト値はそれにハードコードされていますか？もしそうなら、実行可能ファイルをリバースエンジニアリングして取得することはできませんか？
2. 塩がランダムに生成される場合、それを複製する何らかの方法が必要だと思います。では、ランダムなソルトを返す関数をリバースエンジニアリングして、ソルト値を取得するためにそれ自体を複製するように強制することはできませんか？
3. これは範囲外かもしれませんが、（クライアント/サーバー関係の）サーバー側でsalt値が生成される場合、サーバーから送信されたデータを復号化できるように、クライアントと共有する必要はありませんか？そして、それがクライアントに送信されている場合、それを傍受して役に立たないようにすることはできませんか？
4. この「salt」値以外に、8文字の文字列を強力な暗号化キーに変換できる他の方法はありますか？

ハッシュ化されたパスワードとソルト値についてのアイデアがありました。私はハッシュと暗号化にかなり慣れていないので、これを投稿したいと思いました。ユーザーアカウントごとに一意のソルトを生成し、ソルトとハッシュ値をデータベースに保存する方が安全でしょうか? または、単一のソルト値を安全に保存しておき、パスワードをハッシュするたびにそれを再利用しますか?

たとえば、ユーザーは次のパスワードを使用します。

私のコードは、次のソルト値を生成します。

次に、結果をハッシュして取得します。

ハッシュされた結果とソルトは、アカウントが作成されたときに、ユーザー プロファイルのデータベースに保存されます。その後、ユーザーがログオンするたびに新しいソルトが生成され、パスワードとソルトが再ハッシュされてデータベースに保存されます。

何かご意見は？私が言ったように、これは私が持っていたアイデアの健全性チェックです。

パスワードをソルトする最良の方法を教えてください。どちらの方法が最適ですか？

ありがとうございました。

ソルトを生成し、(bcrypt などを使用して) パスワードをハッシュしたら、結果を文字列またはバイト配列としてデータベースに保存するのが最善でしょうか? どちらにしてもメリットはありますか？それとももっと主観的な判断ですか？

現在、いくつかのASP.NET MVC 2サイトを構築していますが、パスワードをソルトするためのオプションは何でしょうか。私のPHPの仕事では、通常、ユーザーが登録したときのタイムスタンプを取得し、SHA1を使用してすべてをハッシュする前に、パスワード文字列の最後にタイムスタンプを追加しました。私の本能は、このアプローチでは不十分かもしれないということです。

とにかく、私はASP.NETを使用したユーザー管理にかなり慣れていないので、最初からベストプラクティスを開始することが私の最大の利益になると思います。ASP.NET Webフォームには組み込みのユーザー管理が利用できることは知っていますが、MVCについてはよくわかりません。

ユーザーパスワードのハッシュが機能しない理由を理解するのに苦労しています。

これを行う方法は通常の方法で、登録時にランダムソルトを作成し、パスワードと組み合わせて保存しますが、ログイン用のパスワードを一致させようとすると失敗します:(

メソッドに渡されるすべての変数は生であり、ソルトまたは暗号化されておらず、単に検証されています：/

よろしく

誰かが塩漬けがどのように機能するかを理解するのを手伝ってくれませんか？

これまでのところ、私は次のことを理解しています。

1. パスワードを検証する
2. ランダムな文字列を生成します
3. パスワードとランダムな文字列をハッシュして連結し、パスワードフィールドに保存します...

ソルトを保存するにはどうすればよいですか、またはユーザーがログインしたときにソルトが何であるかを知るにはどうすればよいですか？独自のフィールドに保存しますか？そうでない場合、アプリケーションはどのようにして塩が何であるかを把握しますか？そして、それを保管するのであれば、それは目的全体を打ち負かしませんか？

更新：ソルトとは何か、レインボーテーブルとは何か、辞書攻撃とは何か、ソルトの目的とは何かを尋ねているのではないことに注意してください。私は質問しています：ユーザーがソルトとハッシュを知っている場合、パスワードを計算するのは非常に簡単ではありませんか？

私はプロセスを理解しており、いくつかのプロジェクトで自分で実装しています。

保存するデータベース：

私が見たソルティングのすべての実装は、パスワードの最後または最初にソルトを追加します。

したがって、彼のソルト（ha ha）の価値があるハッカーからの辞書攻撃は、上記の一般的な組み合わせで保存されているソルトに対して各キーワードを実行するだけです。

確かに、上記の実装は、根本的な問題を実際に解決することなく、ハッカーに別のステップを追加するだけですか？この問題を回避するための代替手段はありますか、それとも私は問題を誤解していますか？

私が考えることができる唯一のことは、ソルトとパスワードをランダムなパターンで組み合わせたり、ハッシュプロセスに他のユーザーフィールドを追加したりする秘密のブレンドアルゴリズムを使用することです。つまり、ハッカーはデータベースとコードにアクセスして、レースを行う必要があります。実りあることを証明するための辞書攻撃のためにそれらを。（コメントで指摘されているように、更新します。ハッカーがすべての情報にアクセスできると想定するのが最善であるため、これはおそらく最善ではありません）。

ハッカーがパスワードとハッシュのリストを使用してユーザーデータベースをハッキングすることを提案する方法の例を挙げましょう。

ハッキングされたデータベースのデータ：

一般的なパスワード辞書：

ユーザーレコードごとに、共通のパスワードをループしてハッシュします。

これが私の主張をよりよく示していることを願っています。

10,000個の一般的なパスワードと10,000個のユーザーレコードがある場合、できるだけ多くのユーザーパスワードを検出するには、1億回のハッシュを計算する必要があります。数時間かかる場合がありますが、実際には問題ではありません。

クラッキング理論に関する最新情報

私たちは破損したウェブホストであり、SHA1ハッシュとソルトのデータベースにアクセスし、それらをブレンドするためのアルゴリズムを持っていると想定します。データベースには10,000のユーザーレコードがあります。

このサイトは、GPUを使用して1秒あたり2,300,000,000のSHA1ハッシュを計算できると主張しています。（実際の状況ではおそらく遅くなりますが、今のところはその引用された図を使用します）。

（（（95 ^ 4）/ 2300000000）/ 2）* 10000=177秒

最大長が4文字の95個の印刷可能なASCII文字の全範囲を、計算速度（可変）で割った値を2で割った値（パスワードを検出するための平均時間が平均して50％の順列を必要とすると仮定）の場合、10,000ユーザーは、長さが4未満のすべてのユーザーのパスワードを計算するのに177秒かかります。

リアリズムのために少し調整してみましょう。

（（（36 ^ 7）/ 1000000000）/ 2）* 10000=2日

大文字と小文字を区別せず、パスワードの長さが7文字未満で、英数字のみを使用すると、10,000ユーザーレコードを解決するのに4日かかります。また、オーバーヘッドと非理想的な状況を反映するために、アルゴリズムの速度を半分にしました。

これは線形ブルートフォース攻撃であることを認識することが重要です。すべての計算は互いに独立しているため、複数のシステムで解決するのに最適なタスクです。（つまり、実行時間の半分になる異なる端から攻撃を実行する2台のコンピューターを簡単にセットアップできます）。

このタスクをより計算コストの高いものにするために、パスワードを1,000回再帰的にハッシュする場合を考えると、次のようになります。

（（（36 ^ 7）/ 1 000 000 000）/ 2）*1000秒=10.8839117時間

これは、 1人のユーザーの引用符で囲まれた数値から半分以下の速度で実行される最大7文字の英数字を表します。

1,000回の再帰的なハッシュは、包括的攻撃を効果的にブロックしますが、ユーザーデータに対する標的型攻撃は依然として脆弱です。

ColdFusionを使用していますが、パスワード用にランダムなソルトフィールドを生成したいと思います。ここでCreateUUID（）関数が役立つかどうか疑問に思いました。別の関数を使用してソルト文字列を作成する例をたくさん見つけました。しかし、代わりにrand（）またはCreateUUID（）関数を使用できるのに、なぜこれを行うのでしょうか。わからない。

それはやり過ぎですか、それとも良い考えですか？または、代わりにrand（）またはタイムスタンプを使用する必要がありますか？

パスワードやその他の重要な情報のデータベースが危険にさらされた場合に、ハッシュに追加されたソルトがセキュリティの向上にどのように役立つかを理解するのに苦労しています。

たとえば、ソルトが「hello」で、パスワード「password」に追加された場合、ソルトとパスワードは「hellopassword」と一緒に保存され、ハッシュされて生成されます。

塩を追加して：

これはどのように安全ですか？攻撃者はソルトを知っているので、パスワードを簡単に計算できます...そうですか? それとも、根本的に何かを誤解していますか？