適度なセキュリティ要件を持つWebサービスを設計していたとします。ほとんどの場合、脅威モデルは退屈な大学生に関するものであり、スパイ小説でこれまでに見つけたものに関するものではありません。次のパスワードストレージスキームを使用することで、実際に何か問題がありますか？
塩|| ハッシュ（サイト||パスワード||ソルト）
ここで、siteはサイトの一意の識別子、passwordはユーザーパスワード、saltはユーザー固有のランダムソルト、hashはSHA-1などの汎用暗号化ハッシュ関数です。|| 連結を示します。
私はこのスキームを思い付く特定の問題を認識しています。
ハッシュは（高速に設計されて）評価が速く、1回の反復では、特定の弱いパスワードが推測可能になります。
連結だけでは、ハッシュへの入力全体に「しゃれ」が発生する可能性があります。
現在、インターネット上に特定のセキュリティ専門家がいて、これが十分に優れたパスワードハッシュスキームの私の考えである場合、私はおそらく雇用に値することはできず、必死に学校に戻る必要があると信じさせます。彼らは、セキュリティの観点からはるかに優れたプロパティを持つよく知られたパスワードハッシュスキームがあることを指摘しています。彼らは私がもっと良いものに切り替えることを要求します。
しかし、本当に、私はすべきですか？ここに少し反論があります。
これはおそらく私のサービスの中で最も弱いリンクにはならないでしょう。本当に侵入しようと決心した人には他にもたくさんの道があります。私は自分の時間を優先して弱い道を確保する必要があります。
私のサイトに本質的な価値がほとんどない場合、費用便益はすでに攻撃者の利益に反しています。大規模なクラスター/ボットネットが1日/週で弱いパスワードを回復する可能性があることは実際的な懸念のどれくらいですか？確かに、その日/週に行うことには、より価値のあることがあります。
トロイの木馬、キーロガー、ソーシャルエンジニアリング攻撃などが原因で、アカウントが侵害される可能性が高くなります。テクノロジーは、このセキュリティの制限要因ではありません。
私のスキームが複雑になるほど、別のプラットフォームに移動/拡張するのが難しくなる可能性があります。私がbcryptを（仮に）使用した場合、bcryptラッパーを作成して組み込む必要がある可能性があります。
私はこのスキームが本当に好きです。とても簡単です。実装を間違えるのは難しいです。そして私は、平均的なサイトに関するすべての意図と目的のために、それは問題ないはずだと主張します。より良いハッシュスキームを導入するように私に頼むことは、チェーンソーに対してすでに非常に脆弱であるドアに大きなロックをインストールするように私に頼むように聞こえます。
私がここで何か間違ったことをしているとしたら、特に実際的で現実の世界に当てはまる懸念の観点から、誰かがそれを指摘してくれることを非常にありがたいです。
ありがとう。