上司に塩を使用するよう説得する
私のマネージャーは、アクティブなWebサイトに加えてすべてのネイティブ言語が異なるため、人々が同じパスワードを使用する可能性が低いため、パスワードをソルトする必要がないと述べています。これに対する最善の反論は何ですか？
どこから来たのかわかりません。まず第一に、彼の意見は [〜＃〜] nist [〜＃〜] で定義されている考慮された業界のベストプラクティスに反対です。さらに、マネージャーは危険なほど間違っています。ユーザーが多いほど、複数のユーザーに対して同じパスワードを取得する可能性が高くなります。また、以下の企業がそれを行っており、あなたのウェブサイトよりもグローバルなユーザーベースが大きいと確信しています。
- フェイスブック
- Gmail
ビジネスの観点から説明できるもう1つの理由は、イメージ/ブランドの損傷のリスク否定的な宣伝を取得します。例を示すために、アドビは現在と同じ問題につながるパスワードストレージの不適切な実装を使用しました：ハッシュの結果の値（アドビの場合、ハッシュではなく暗号化を使用していました）パスワードはいくつかで同じでしたユーザーが同じパスワードを使用していた場合（対称暗号化の実行中にIVを使用しなかったためですが、これは関係ありません）。これは否定的な宣伝の大規模な嵐を引き起こしました、結局のところインターネット会社はパスワードハッシュのような単純なものに固執しているはずですか？そのような否定的な宣伝から生じる財政的費用は、かなりの額になる可能性があります。
また、あなたが住んでいる国や採用されている法律にもよりますが、最近、過失であると判断された場合、経営陣は個人的に責任を負うことができますデータのプライバシーを保護することになります（たとえば、クラックされたパスワードを使用してユーザーの個人データを取得する場合）。また、保存されている情報の種類、財務、医療、クレジットカードに応じて、さまざまな規則が適用される場合があり、他の種類の罰金にもなる可能性があります。
これは、パスワードハッシュには直接関係ないかもしれませんが、マネージャーがさらに悪い決定をした場合に役立つかもしれません。そのため、問題を明確に説明するメールのコピーを作成し、マネージャーの返信を保存してください。 （自分のお尻をカバーするためだけに）
ソルトを使用していないという事実は、正しいハッシュアルゴリズムを使用していないことも意味します。これは、ソルトの生成と多くの反復の実行を処理することが多いためです。受け入れられている3つのアルゴリズムは次のとおりです。
- PBKDF2
- bcrypt
- 暗号
Saltの主な目的は、計算された単一のハッシュと保存されているすべてのハッシュを比較することで、攻撃者が作業を保存できないようにすることです。この問題は、パスワードが一意であるかどうかとは無関係です。
ソルトがない場合、攻撃者は考えられるパスワードのリストを調べ、それぞれのハッシュを計算し、結果が格納されているハッシュのいずれかに一致するかどうかを確認するだけです。したがって、推測ごとに1つの計算のみが必要です。
Saltを使用すると、攻撃者は結果を再利用できないため、ユーザーごとにリストを確認する必要があります。これにより、彼は推測ごとに1つの計算およびをユーザーごとに実行する必要があります。これにより、攻撃のコストが大幅に増加します。
しかし、ルーカスがすでに述べたように、ここでの本当の問題は、適切なアルゴリズムを使用していないことです。ソルトは、パスワードハッシュの1つの側面にすぎません。
「最良の」反論は、何を達成しようとしているのかに依存します。
科学的に正しくなりたいだけの場合、塩は、同じパスワードを選択する2人の異なるユーザーに対処する方法ではなく、今までにない方法であると言えば十分です。特に、たまたま同じパスワードを選択した2人のユーザーは最初から問題ではないため、修正する必要はありません。ソルトは、事前計算されたテーブルの使用を含む、並列攻撃を回避するためのものです。塩の欠如は LinkedIn の主要な罪でした。
現在正しいことは、自分が間違っているか、少なくとも不完全な情報を含んでいる可能性があることを認める準備ができている人々にのみ影響します。あなたが上司から引用したものは、彼がその主題に関して完全に無能であると同時に、彼が完全にそれを習得していると確信していることを実証する傾向があります。そのマネージャーが彼が間違っていることを納得させたいなら、それで、それで大運。人々が最も恐れているのは、暗黙的にであっても、彼らが愚かなことを言ったことを認めていることです。
組織が実際に適切なパスワードハッシュに切り替えたい場合（-- this を読み取る）、次にできることができること他の人々に、マネージャーが言ったことは単なる意味不明なことであり、実際には間違っている意味もないことを納得させることです。管理者が孤立した場合、当然ながらそれを認めることなく、適切なパスワードハッシュの実装に目を向けることがあります。ここでも、科学的に正しい議論は必ずしも最も効率的なものではありません。北米（特にニューイングランドのようなイギリスの影響を受けた地域）では、ビジネス会議は衝突の回避と責任の希薄化に関するものであるため、いくつかを広める必要があります 恐怖、不確実性、疑い ：あなたの競合他社はソルトハッシュに切り替えており、同じ操作を行わないと、市場シェアを失うリスクがあります。南ヨーロッパでは、会議は階層を確立するための儀式の戦いです。そのため、叫び、うなり声、脅迫、皮肉を使用して群衆の支持を獲得します。正しいことで勝利することはありません、しかしassertive。
一般的に言えば、最も効率的なタイプの議論の1つは、権威への訴えです。 NIST Special Publication SP800-118 （現在はドラフト版）では、次のように表示されます。
ハッシュアルゴリズムの弱点のもう1つの例は、一部のアルゴリズムがソルティングを使用しないことです。
「塩分なし」=「弱さ」。 NISTはそう言っています。彼がNISTより賢いと思っているこのマネージャーは誰ですか？
ある意味で、もしあなたが塩について議論しているなら、あなたはすでにボートに乗り遅れました。 パスワードストレージのセキュリティに関する最新技術は、「ソルトするかしないか」という問題をはるかに超えており、繰り返しのカウントに移っています。
しかし、基本から始めましょう。少し前に書いた、驚くほど人気のあった答えがここにあります。それは塩がより良い理由を説明し、多くの人々は他の説明がうまくいかなかったところに何かクリックしたと言っています。それは多かれ少なかれあなたが求めていることです-それがいくつかの良いことをすると思うなら上司にそれを見せてください：
しかし、重要な点は、そこで行われた最後のものです。つまり、ソルト処理されたSHA1ハッシュを保存してそれを有効と呼ぶことは、もはや責任があるとは見なされません。コンピューティング能力は、1秒あたり数十億回のハッシュが理論的ではなくなった時点に達しており、ブルートフォース攻撃の32ビット空間全体を、自分が何をしているのかを説明するのにかかる時間よりも速く突破することができます。
現在の焦点は、攻撃者が問題を数千回または数十万回解決するように強制して、推測することです。ここにPBKDF2が表示され（そのNIST発行のスーツとネクタイを着用）、scryptと友達（だらしないように見えますがパワフル）。
どのアルゴリズムを選択するかは、実際には重要ではありません。それらはすべて、ほぼ同じ問題を、異なる強調点を使用した異なる方法で解決します。しかし、somethingを使用する必要があります-単一のパスワードでさえ総当たりすることを困難にするいくつかのアルゴリズム。その理由は単純です。これは業界標準であり、測定可能かつ証明可能な程度に安全であり、それを使用するための大きなコストは発生しないためです。これらの要因をまとめると、しない場合、違反が発生した場合に過失と見なされる可能性があることがすぐに明らかになります。
最良の議論は 最も一般的なパスワードのリスト を引き出して、ユーザーの約1％が「123456」を選択することを示すことです。次善の策は、 大規模サイトのパスワードリーク分析 を引き出して、ユーザーの約半分だけが独自のパスワードを考え出すことを示すことです。
あなたは2つのポイントを作る必要があります：
ソルトを使用すると、ハッシュされたパスワードを含む盗まれたファイルの価値が減少します。これは、システムのユーザーが話す言語に関係なく当てはまります。これは、ハッシュアルゴリズムにRainbowテーブルを持っている攻撃者がそれを使用して、選択した人の母国語に関係なく、ハッシュされたパスワードを元に戻すことができるためです。パスワード。
塩の使用はほぼ無料です。それを除外してもほとんど何も得られません。また、マネージャーの現在の見積もりでさえ、除外しても「重大な」セキュリティ上の問題を引き起こさない可能性があります。したがって、それを使用してください。
あなたのマネージャーが最初の点に対して提起するかもしれないという異論がありますが、私はできません：「私たちは独自のカスタムハッシュアルゴリズムを使用しているので、それにレインボーテーブルが存在する危険はありません」。その場合、標準のパスワードハッシュアルゴリズムを使用するために、またはを使用する必要があります。
私も見つけます：
[ユーザー]すべてが異なる母国語を持っている
システムについて行う奇妙な仮定であること。セキュリティ分析の前提に依存している場合、前提が破られるとすぐに、システムは安全でなくなります（またはいずれにしても、セキュリティの評価は行われません）。したがって、セキュリティについてこの仮定に依存していたため、次にそのことを強制する必要があります製品の2人のユーザーが同じ母国語を使用することはありません。なぜ誰もがそのようにシステムを制限したいと思うのはなぜですか。特に、この制限を強制することは、ソルトを使用するよりも簡単でしょうか？
ただし、この場合、その仮定では、ソルトは不要であるという結論に至ることはありません（上記で説明した理由により）。したがって、仮定が維持できるかどうかの問題は、それが役に立たないという事実に直面しても、かなり無関係です！
最後に参考までに、上記の最初の点が上司の分析と矛盾する特定の理由があります。
同じパスワードを使用する可能性は低い
ソルトが対処する弱点の欠陥のある分析です。システムの2人のユーザーが同じパスワードを持っているかどうかは、攻撃者にとって重要ではありません。ただし、攻撃者がたまたま2人のユーザーの1人であり、したがって、共有するパスワードを知っている場合を除きます。ソルトはこの攻撃を防御しませんのみレインボーテーブル攻撃を防御します。したがって、ユーザーの1人によるこの珍しい同じパスワードによる攻撃がシステムで不可能であったとしても、ソルトが必要になります。
これは技術的な問題というより、人の問題だと思います。したがって、技術的な説明ではなく、ソフトスキルで対応する必要があります。上司が技術的な説明に積極的に反応する場合は、以前に答えの1つを選択してください。
ソフトスキルの側面に進みたい場合は、いくつかのことを試すことができます。
- 覚えておくべき最も重要なこと：あなたの上司はあなたの上司です。彼に腹を立てないでください。怒らないでください。
- 彼が答えることができない質問をしないようにしてください。代わりに、簡単な文章の形で間接的な質問をしてください。
- 彼の立場と議論を理解してみてください。
- 言い換えを適用します。
- 決して笑わないで。
- 失礼なことはしないでください。
- デール・カーネギーの本「友達を獲得して人々に影響を与える方法」を読んでください。
ダイアログの例は次のようになります（私は英語のネイティブスピーカーではないことに注意してください）。
ボス：「私たちは塩は必要ありません。」
あなた：「追加の保護は必要ありません。」
ボス：「はい、ユーザーは同じパスワードを再利用しません。」
あなた：「強力なパスワードはすでに安全です。」
ボス：「そうです。」
あなた：「わかりました。わかりました。ユーザーはパスワードを安全にしていて、塩を使わずに暮らしています。」
ボス：「ええ、たぶんすべてのユーザーではない...」
あなた：笑顔
またはこのように：
ボス：「私たちは塩は必要ありません。」
あなた：「塩を使用する利点は、努力する価値がありません。」
ボス：「その通りです。」
あなた：「タスクリストからソルトを削除して、残りを続行します。」
ボス：「そうです、すでに予定より遅れています。」
あなた：「別の方法でスケジュールを満たせば、ソルトを実装できますか？」
ボス：「いいえ、そのソルトの概念がわかりません。」
あなた：「その暗号に関するものは常に理解するのが難しい」
ボス：「記事を読んでも手がかりがありませんでした。」
あなた：「どれが大変なことだと思わせるか」
ボス：「はい、2日ほどで負けます。」
あなた：「フレームワークの助けを借りて、私は2時間でそれを行うことができます。」
ボス：「本当に？」
あなた：笑顔
疑問符はまったくないことに注意してください。上司は、彼が答えを知らないかもしれない質問に答えるというプレッシャーを受けることは決してありません。
残念ながら、あなたがこれまでやったことがない場合、そのような技術を適用することは非常に困難です。
この方法でもうまくいかない場合は、もう1つのオプションがあります。
実装するだけです。コードレビューを行ったり、データベーステーブルを調べたりしている場合を除いて、上司は気付かないでしょう。
ハッシュ（おそらく彼自身のパスワード）をGoogleに投げるだけです。ほとんどの場合、パスワードを返します。彼の弱いハッシュはハッシュをまったく行わないようなものです。
https://www.google.de/search?q=a94a8fe5ccb19ba61c4c0873d391e987982fbbd
それでも納得しない場合は、新しい仕事を探します...