database - ング - ハッシュ化 戻す



暗号化されたユーザー名ハッシュをデータベースに格納する (4)

私は現在、まとめているアプリの基本的なユーザー認証に取り組んでいますが、セキュリティに関する経験はあまりありません。

これは、パスワード(暗号化されているかいないか)とは対照的に、(塩漬けの)パスワードハッシュをBLOBとしてデータベースに塩漬け/保存することの実際(そして必要性)を理解しているということです。 私はすでにこれを実装しました。

プレーンテキスト(または暗号化された)のユーザー名とは対照的に、ユーザー名をソルトにしてハッシュ化し、ハッシュをデータベースに格納することによって得られるものはありますか? 認証にデータベースを使用してどのユーザーがシステムにアクセスできるのかを判断するのはかなり困難になります。

誰かがユーザーアカウントのパスワードを解読するのを困難にすることが重要であるため、どのユーザーが実行可能であるかを判断することの難しさを増すことも意味がありませんか?

編集:それは私が使用している言語のいくつかは100%正しいではない可能性があります:訂正すること自由に感じなさい:-)

編集2:私は塩味のハッシュを示すために私の最初のポイントの1つを変更しました - 私がこれを逃したことを指摘してくれてありがとう:-)

編集3:パスワードを暗号化/復号化していることを示す文言を削除しました。 私は塩味のハッシュを使用しており、それをDBに保存しています。これを指摘してくれたScottyに感謝します。

https://src-bin.com


Answer #1

状況によります

あなたが提供している素材の感度を評価することは重要です。 さらに深く掘り下げるために、いくつかの使用例を示します。

シナリオ1:ソーシャルネットワーキングアプリケーション

ユーザーのやりとりはすべて公の場で行われます。 彼らのEメールアドレスは彼らのユーザー名として使われます。 彼らの名前がす​​べての投稿に表示されるので、そこにユーザー名は非公開とは見なされません。 ユーザー名が他のユーザーによって検索されているか、電子メールによる招待が有効になっています。

評決 - ハッシュ=悪い

シナリオ2:Eコマースサイト

ユーザは、公の交流に参加してもしなくてもよい(例えば、コメント、レビュー)。 ユーザー名として電子メールアドレスを使用することは、おそらく悪い考えです。パスワード回復を使用することで、侵害された電子メールアカウントはサイト上の侵害されたユーザーアカウントを意味するためです。

ここには灰色の領域がたくさんあり、通常は「利便性」のために利用されています。 あなたのサイトがユーザー名として電子メールを使うならば、発送歴とクレジットカード番号を保存します。 電子メールが侵害されると、ユーザーにとっての個人情報の盗難による多くのトラブルが発生する可能性があります。

この場合、ユーザー名ユーザーの電子メールアドレスではないというポリシーを使用することをお勧めします。 電子メールをハッシュしても価値はありません。

注:私はあなたのAmazon.com見ています。

評決:慣習!=良い習慣

シナリオ3:ポルノサイト

ユーザー名を仮名にし、ログイン名をユーザーの電子メールアドレスにします。 彼らはそのコンテンツについて話をしたいと思うかもしれず、必ずしも彼らの名前がsmutサイト​​に対するGoogleの結果に表示されることを望まないかもしれない。

ここで最悪の事態を想定してください。 どういうわけかあなたのデータベースがハッキングされていると、あなたのユーザーのアイデンティティの露出は取り返しのつかない損害を引き起こすかもしれません。 これがあなたに起こるとは思わないのですか? この記事を見てください

ユーザーのアカウントがハッキングされ、パスワードが公開されるだけでなく、それらのユーザーの多くが自分の電子メールアカウントで同じパスワードを使用している可能性があります。 今、彼らの情報は全世界が見ることができるようにPasteBinに匿名で投稿されています。 さらに悪いことに、ほとんどの人はおそらくこれがまだ起こっていることさえ知らないでしょう。

単にユーザー名とパスワードの両方をハッシュすることによって、彼らは自分自身と彼らのユーザーを全体的に多くの面倒を救っていたでしょう。

評決:ユーザー名として使用されているかどうかにかかわらず、電子メールアドレスを確実にハッシュします。

シナリオ4:銀行

言うまでもありませんが、銀行/金融サイトに関しては、費用を節約するべきではありません。

セキュリティを強化することができます:

  • メールアドレス以外のユーザー名を使用する
  • 数字と文字を必要とすることでユニークなユーザー名を強制する
  • ハッシュパスワード
  • 2点認証を要求する(ユーザーの電子メールパスワードが危険にさらされた場合)
  • 電子メールアドレスのハッシュ
  • 等...

ユーザーを保護するために費用を節約するべきではありません。そうしないと、自分の生計でギャンブルをしていることになるからです。

結論:

すべてのサイトに適用されるセキュリティのための厳格で迅速な規則はありません。 場合によっては、ユーザー名が公開されるため、ハッシュしても価値がありません。 他人では、それをハッシュ化しないと、取り返しのつかない損害を引き起こす可能性があります。 ユーザー名/電子メールのハッシュを有効にすることができるサイトを開発することになったら、これが良い方法です。

  1. ユーザー名をハッシュする
  2. ユーザーに固有のsaltを生成します
  3. saltを使ってパスワードをハッシュする
  4. データベースにソルトとともにパスワードを保存する

ユーザー名を塩でハッシュしないことで、鶏肉/卵子の問題を回避できます。 あなたがすべてのユーザ名に静的ソルトを使わない限り。

すべてのユーザーアカウントの静的ソルトは、コードを読むことで見つけることができます。 静的な塩が見つかったら、レインボーテーブル攻撃を使用したときには本質的に役に立ちません。 パスワードを偽造する場合は、動的なsaltを生成し、それを他のユーザーの資格情報と一緒にデータベースに格納します。

あなたが簡単のために難しい/速い規則を望むなら、ここに覚えておくべきいくつかの良い仮定があります:

  • データベースがある時点で侵害される可能性があるとします。
  • あなたのソースコードがある時点で危険にさらされると思います
  • ユーザーの電子メールがある時点で侵害されると想定します。
  • あなたのユーザがダムで、彼らのEメールに使うのと同じパスワードをあなたのサイトに使うと仮定します
  • ハッカーが賢く/リソースが豊富で経済的に動いていると仮定します。

機密データや個人データを保存することを選択した場合、追加の手順を実行することで、将来的にPR /法的な悪夢を防ぐことができます。

更新: シードハッシュについての興味深い記事がCoding Horrorに掲載されました


Answer #2

簡単な答え:たぶんいいえ。

長い答え:あなたの状況には「私のユーザー名は...のために機密である」というキーが欠けているように思われます。

その問題がなければ、あなたが説明しているのはセキュリティ関連の開発(そして実際には全体としての開発)における一般的な落とし穴です。 。 ソフトウェア開発におけるものと同様に、特定のツールを使用することによってのみ解決できる明確な問題が現れるまでは、必要とされること以外のことは何もしないでください。

追加のヒント(無料): パスワードハッシュを無効にします 。 普通のハッシュははるかに安全性低いです。


Answer #3

システムの一部を単独で見ても、システムのセキュリティを正しく評価することはできません。 パスワードを復号化するための鍵をどこに保管していますか?

データベースにアクセスできる人は、暗号化キーを格納している場所にもアクセスできますか? もしそうなら、あなたはパスワードを暗号化することによってセキュリティのマイナーな改善を得ただけで、おそらくユーザー名を暗号化することによって得ることになるものはそれ以上ないでしょう。

復号化キーとそれを使用するプログラムがデータベースより安全である場合(これは非常に珍しいことですが、通常、データベースは可能な限り最も安全な場所にあります)、攻撃者を奪うようにユーザー名も暗号化することに追加の利点があります。総当たり攻撃における有用な情報の提供。


Answer #4

データベースにアクセスできる人はだれでも自分のパスワードを見ることができるので、自分のパスワードをプレーンテキストで保存することは、ユーザーにとってそれほど公平ではありません。 塩味のハッシュを使うべきです。

Salt_(cryptography)





security