問題タブ [salt]

だから私はゲームのウェブサイトを作っています。人気になるものはありません：P

今はパスワードのセキュリティを考えています。ソルティングを使用しますが、アカウントテーブルに新しい列を追加する代わりに、アカウント名は変更できないため、ソルトとして使用することを考えていました。これは「一意」です。つまり、2人のユーザーが同じアカウント名を持つことはできません。

でも、誰かがバナナというアカウント名を持っているとしたら、どれほど安全かと思っていました。つまり、ハッカーが使用するこれらの単語リストでは、単語が人気があるということです。

アカウント名がバナナで、パスワードがhello（sha1でハッシュ化）であるとしましょう。これは簡単に元に戻すことができますよね？

私は疑問に思っていました-何かのハッシュをそれ自体のソルトとして使用することに不利な点はありますか?

例 hashAlgorithm(data + hashAlgorithm(data))

これにより、ルックアップ テーブルが使用されなくなり、データベースにソルトを保存する必要がなくなります。攻撃者がソース コードにアクセスできない場合、攻撃者はアルゴリズムを取得できず、ブルート フォース攻撃が非常に困難になります。

考え？（これは悪いことだと直感していますが、本当にそうかどうか、もしそうならその理由を確認したかったのです。）

どれだけ強いだろう

ただと比較される：

$saltは、強力なランダムASCIIで構成される長さ12のユーザーごとの文字列です。

ユーザーパスワードを2つの異なるソルト文字列でハッシュすることを考えています。1つはすべてのユーザーに同じコードに保存され、もう1つは各ユーザーが独自の値を持つデータベースに保存されます。

これは単にデータベースに値を保存するよりも効果的でしょうか?

アドバイス、意見をお待ちしております。

ありがとう

grails の acegi 0.5.2 プラグインでパスワードをエンコードするときに、カスタム ソルトを指定する必要があります。

ユーザーのパラメーター (おそらくユーザー名) を使用して ReflectionSaltSource を使用する方法を示すチュートリアルを見つけました。しかし、私はそれを機能させることができませんでした。実際には、使用するユーザーのプロパティを選択するだけでなく、ソルトを制御できる必要があります。

具体的には、ソルトをフォーマットに一致させてから、<hard coded string>_<some user specific property>_<the password>その文字列をエンコードする必要があります。これは、レガシー システムとの互換性のために必要です。

これはacegiとgrailsで可能ですか? もしそうなら、どのように？

Hashing User Passwordsに関する DavidHayden の記事の 1 つを読んでいたところです。

本当に私は彼が達成しようとしていることを理解できません。

彼のコードは次のとおりです。

パスワードをハッシュしてソルトを追加するための他の C# メソッドはありますか?

ハッシュ ダイジェスト生成機能をコード ベースに追加する作業を行っています。String をハッシュ ソルトとして使用して、既知のキー/パスフレーズをハッシュする必要があるものの先頭に追加できるようにしたいと考えていました。私はこの概念を誤解していますか？

ログインシステムにsaltを実装したいのですが、これがどのように機能するかについて少し混乱しています。その背後にある論理が理解できません。md5は一方向のアルゴリズムであり、私が遭遇したすべての関数はすべてを一緒にハッシュしているように見えることを理解しています。この場合、比較のためにパスワードを元に戻すにはどうすればよいですか？私の最大の質問は、単にパスワードをハッシュするよりも、ユーザーのパスワードをソルトする方が安全なのかということです。データベースが危険にさらされた場合、ソルトとともにハッシュがデータベースにあります。ハッカーが必要とするのはこれだけではありませんか？

私はまた、別の開発者が言ったSOに関する別の投稿を見つけました：

「ソルトとアルゴリズムがデータベースとは別に保存されていることを確認してください」

ソルトをデータベースに保存したいのですが。私がそうするなら、これは本当に問題ですか？

これがどのように機能するか、またベストプラクティスが何であるかを理解するための助けを探しています。どんな助けでも大歓迎です。

編集：私は皆の反応とアイデアに感謝したいと思います。今はもっと混乱しているかもしれませんが、それは確かに私にとって学習体験でした。みんなありがとう。

私は昨日ここにいて、本当に素晴らしい答えをいくつか得ました。私が得たものをまとめてみると、かなり安全なアルゴリズムになると思います。ソルトを生成する for ループでフグを使用すると問題が発生します。

base64 文字と for ループを使用してランダムな文字列を取得しています。この生成された文字列を取得し、crypt 関数にソルトとして挿入します。

フグに関するドキュメントは非常にまばらで、PHP のドキュメントでは実際には言及されていないため、私はここで暗闇を突き刺しています。

本当に奇妙なことは、このコードを現在のように実行すると、失敗しないことです。for ループの上またはcrypt 関数から'$2a$07$' を削除すると、断続的に暗号化された文字列が返されます。フグについての私の理解では、暗号化された文字列は「$2a$07$」で始まり、「$」で終わる必要があるため、crypt 関数で連結されます。for ループの上の最初の文字列は本当に必要なく、取得したかっただけです。それを取り除きます。

また、ランダムソルトをデータベースに保存するか、暗号化関数の出力をデータベースに保存することで、ベストプラクティスについて明確にしたいと思いますか?

昨日、本当のコードが投げかけられることはなく、議論だけでした。今日はいくつかのコードをまとめて、かなり安全なものを用意したいと思います。誰かがより良いアルゴリズムを思い付くことができれば、私はいつでもオープンです.

パスワードの保存に関する Jeff Atwood の投稿を読んだ後、私は BCrypt.net に出くわしました。これにより、Thomas Ptacek が BCrypt を使用してパスワードを保存することを勧めました。最終的に、この BCrypt の C# 実装にたどり着きました

上記の最後のリンクのコメントで、誰かが「GenerateSalt(30) には時間がかかるのに、GenerateSalt(31) にはまったく時間がかからないように見えるのはなぜですか?」と尋ねました。

BCrypt.HashPassword(password, BCrypt.GenerateSalt(31)) を実行したところ、0 ミリ秒で結果が得られました。

BCrypt.HashPassword("password", BCrypt.GenerateSalt(30)) を 5 分以上実行していますが、まだ結果がありません。

パスワード ハッシュ (またはBCrypt の場合は元に戻せない暗号化)を作成するために、ランダムに生成された 30 文字のソルトはおそらく何年も必要ないでしょう。編集私はコードを少し読むべきでした.logRoundsはソルトの長さとは何の関係もありません. ありがとうアーロノート。

では、GenerateSalt(31) がほぼ瞬時に値を返すのはなぜですか (GenerateSalt(30) の約 2 倍の時間がかかるのに)。

アップデート

ここに修正があります：