データベースに平文で保存したくないパスワードを扱う適切な方法は何ですか? NHibernate / Castle ActiveRecord のオプションは何ですか?
更新: 他の人が NHibernate / Castle ActiveRecord でこれをどのように処理するかに興味がありました。そして、NHibernate または Castle ActiveRecord に組み込まれているものがあれば。
データベースに平文で保存したくないパスワードを扱う適切な方法は何ですか? NHibernate / Castle ActiveRecord のオプションは何ですか?
更新: 他の人が NHibernate / Castle ActiveRecord でこれをどのように処理するかに興味がありました。そして、NHibernate または Castle ActiveRecord に組み込まれているものがあれば。
パスワードをハッシュします。暗号化しないでください。暗号化は複雑で安全ではありません。通常の基幹業務アプリまたは Web サイトで、他の検証可能な基準に基づいてパスワードをリセットしても問題ないという状況は考えられません。パスワードのハッシュ化の原理を知っているかどうかの質問からはわからないので、基本から説明します...
ユーザーが最初にパスワードを選択すると、テキストに対して一方向ハッシュ アルゴリズムが実行されます。これにより、署名が生成されます。これは、同じ文字列をハッシュ アルゴリズムに入力した場合に常に生成される出力です。重要なのは、ハッシュからパスワードに戻れないことです (したがって、一方向)。次に、パスワードではなくハッシュを保存します。ユーザーが戻ってきたら、パスワードをもう一度入力する必要があります。同じアルゴリズムを使用してこれをハッシュし、結果の値を DB の値と比較します。一致する場合、ユーザーが同じ文字列を再度入力したことがわかりますが、それでも入力しません。それが何であるかを知りません、または知る必要があります。これは、暗号化に基づくソリューションよりもはるかに安全です。キーがわかっている場合はいつでも平文を復元できます。定義上、パスワード入力を検証するために、キーはサーバーに認識されている必要があります。
.NET で文字列をハッシュする簡単な方法は、 を使用することSystem.Web.Security.FormsAuthentication.HashPasswordForStoringInConfigFile()
です。長い名前にもかかわらず、ASP.NET フォーム認証を使用するユーザー向けに提供されている単純な関数ですが、他の場所でも同じように役立ちます。MD5 または SHA1 をハッシュ アルゴリズムとして指定できます (または、将来のフレームワーク バージョンでサポートされている場合は実際に他のハッシュ アルゴリズム)。MD5には弱点があることが知られているため、SHA1をお勧めしますが、SHA1にもおそらく弱点があります。
ただし、このスキームには欠陥があります。複数のユーザーが同じパスワードを選択すると、ハッシュは同じになります。ハッカーがデータにアクセスすると、ブルート フォース攻撃を実行して一般的な文字列をハッシュし、保存されているデータと比較することができます。ヒットした場合、そのパスワードを使用しているすべてのアカウントをクラックしたことになります。ユーザーは安っぽいパスワードを選ぶ傾向があり、覚えられない安全なパスワードを選ばされることを嫌うため、単純なパスワード ハッシュに基づくシステムは少し脆弱になります。
あなたがすべきことは、ハッシュをソルトすることです。これは、元のデータ (パスワード) の先頭または末尾にランダムな文字列を追加することを意味します。このソルトは可能な限りランダムである必要があり、長さは少なくとも数文字 (最低でも 5 文字をお勧めします)、できればランダムな長さである必要があります。ソルト (難読化されていない) を、ハッシュされたソルト + パスワードの組み合わせと共に DB の列に格納します。ユーザーが戻ってきたら、同じ方法でソルトを入力の先頭または末尾に追加してから、以前と同様にハッシュ比較を行います。
これにより、パスワードが同じであってもすべてのユーザーが異なるハッシュを持つ必要があるため、ブルート フォース攻撃の有効性が低下します。パスワード自体がソルトよりも長く、十分な長さがあれば、ハッシュから文字列を作成することは、文字列の一部を知っている場合とまったく知らない場合と同じように難しいため、ソルトをDBに安全に保存できます。そして、力ずくでクラックするのに長い時間がかかるほど強力です(少なくとも1つの大文字と小文字の変更と数字または非英数字を含む少なくとも6文字)。
誰かがあなたのデータに無制限にアクセスできる場合、最終的にはハッシュ化されたパスワードを解読します。しかし、最終的には数か月または数年になる可能性があります。また、侵害されたことを知っていれば、問題が発生する前に全員のパスワードを変更することができます。
最善の方法は、UserType を使用することです。これは、透過的なパスワード暗号化を実装するものです。
このようなよくある質問をActiveRecord wikiにコピーします。
NullSafeSet() への後続の呼び出しでハッシュされたパスワードを継続的に再ハッシュすることを防ぐ計画がない限り、一方向ハッシュに UserType を使用しないことをお勧めします。
代わりに、Password プロパティでバッキング フィールドを使用し、セッターでハッシュ メソッドを適用し、フィールド アクセスを使用するようにマッピングを設定することをお勧めします。
申し訳ありませんが、あなたにとってはもう関係ないかもしれませんが、他の誰かを助けることができれば幸いです.
uNhAddins を使用するのが私が見つけた最も簡単な方法です。HBM を気にするだけで十分です。
その助けを願って
パスワードを暗号化またはハッシュする必要があります。ハッシングはもう少し安全です(もちろんアルゴリズムによって異なります)。元に戻すことはできないためです。ただし、パスワードの取得オプションを使用できるため、暗号化はより機能的になります。ハッシュでは、新しいパスワードを生成する必要があります..
nHibernate / Castleに関しては、永続メカニズムから分離されたビジネスオブジェクトIMHO内のアルゴリズムを処理する必要があります。