質問に対して私が行ったコメントによると、
1つの重要な点がほとんどすべての人によって非常に見過ごされています...私の最初の反応は、@ stefanwのように、ここの問題は要件が壊れていることに気付くまで、@ Michael Brooksと非常に似ていました、しかし、これらはそれらが何であるかです。
しかし、そうではないかもしれないと思いました。ここで欠けているのは、アプリケーションの資産の暗黙の価値です。簡単に言えば、価値の低いシステムの場合、すべてのプロセスが関与する完全に安全な認証メカニズムは過剰であり、セキュリティの選択は間違っています。
明らかに、銀行にとって「ベスト プラクティス」は必須であり、倫理的に CWE-257 に違反する方法はありません。しかし、それだけの価値がない価値の低いシステムを考えるのは簡単です (ただし、単純なパスワードは依然として必要です)。
真のセキュリティの専門知識とは、適切なトレードオフを見つけることであり、誰もがオンラインで読むことができる「ベスト プラクティス」を独断的に吐き出すことではありません。
そのため、別の解決策を提案します。
システムの価値に応じて、システムが「高価な」資産 (ID 自体を含む) がなく適切に低価値であり、かつ適切なプロセスを行う有効なビジネス要件がある場合にのみ、不可能（または十分に困難/高価）であり、クライアントはすべての警告を認識しています...
その場合、特別なフープを飛び越えずに、単純に可逆暗号化を許可することが適切な場合があります.
暗号化をまったく気にしないとは言いませんが、実装が非常に簡単/安価であり (パスシブルキー管理を考慮しても)、ある程度の保護を提供します (実装コスト以上)。また、元のパスワードをユーザーに提供する方法についても検討する価値があります。これは、電子メール、画面表示などを介して行われます。
ここでの前提は、盗まれたパスワードの価値が (全体としても) 非常に低いことです。これらのソリューションは有効です。
さまざまな投稿や個別のコメント スレッドで活発な議論が行われているため、実際にはいくつかの活発な議論が行われているため、いくつかの説明を追加し、ここの他の場所で提起された非常に良い点のいくつかに対応します。
まず、ユーザーの元のパスワードを取得できるようにすることは悪い習慣であり、一般的には良い考えではないことは、ここにいるすべての人にとって明らかだと思います。それはまったく論争の対象ではありません...
さらに、多くの、いやほとんどの状況では、それは本当に間違っていて、ファウルで、厄介で、醜いことさえあることを強調します.
ただし、問題の核心は、これを禁止する必要のない状況があるかどうか、およびその場合、状況に適した最も正しい方法でどのように禁止するかという原則に関するものです。
さて、@Thomas、@sfussenegger、および他の数人が言及したように、その質問に答える唯一の適切な方法は、特定の（または仮説的な）状況の徹底的なリスク分析を行い、何が危機に瀕しているか、保護する価値があるかを理解することです、およびその保護を提供するために行われているその他の緩和策。
いいえ、流行語ではありません。これは、実際のセキュリティ プロフェッショナルにとって基本的で最も重要なツールの 1 つです。ベスト プラクティスは、ある時点までは (通常、経験の浅い人やハックのためのガイドラインとして) 有効ですが、その後は、思慮深いリスク分析が引き継がれます。
おかしなことに、私は常に自分自身をセキュリティ狂信者の 1 人だと思っていましたが、どういうわけか、いわゆる「セキュリティ専門家」の反対側にいるのです。そして実際の実際のセキュリティ専門家 - 私は、その非常に重要なリスク分析なしで「ベスト プラクティス」のドグマ (または CWE) を吐き出すことを信じていません。
「防御している実際の問題が何かを知らずに、ツールベルトのすべてをすばやく適用するセキュリティ熱狂者に注意してください。より多くのセキュリティが必ずしも優れたセキュリティとは限りません。」
リスク分析、および真のセキュリティ狂信者は、リスク、潜在的な損失、可能性のある脅威、補完的な軽減策などに基づいて、より賢明な価値/リスクベースのトレードオフを指摘するでしょう。彼らの推奨事項の根拠、または論理的なトレードオフをサポートする代わりに、リスク分析の実行方法さえ理解せずにドグマと CWE を吐き出すことを好み、セキュリティ ハッキング以外の何ものでもなく、彼らの専門知識は彼らが印刷したトイレット ペーパーの価値はありません。
確かに、それが空港セキュリティのばかげたことを私たちが得る方法です。
しかし、この状況で行うべき適切なトレードオフについて話す前に、明らかなリスクを見てみましょう (明らかに、この状況に関するすべての背景情報を持っているわけではないため、私たちは皆仮説を立てています。状況が存在する可能性があります...)
LOW-VALUE システムを想定しましょう。ただし、パブリック アクセスほど単純ではありません。システム所有者は、カジュアルななりすましを防止したいと考えていますが、「高い」セキュリティは使いやすさほど重要ではありません。(はい、熟練したスクリプトキディがサイトをハッキングできるリスクを受け入れることは正当なトレードオフです...待ってください、APT は現在流行していませんか...?)
たとえば、今年のキャンプ旅行でどこに行きたいか、誰もがブレインストーミングできるように、大家族の集まりのためにシンプルなサイトを手配しているとしましょう。エルマおばさんが必要なときにログオンできないことを心配しているので、匿名のハッカーや、いとこのフレッドがワンタナマナビキリキ湖に戻るように繰り返し提案することについてはあまり心配していません. さて、核物理学者であるエルマおばさんは、パスワードを覚えるのが苦手で、コンピューターを使うことさえ苦手です。繰り返しますが、私はハッキングを心配しているのではありません。間違ったログインのばかげた間違いをしたくないだけです。誰が来て、何を望んでいるのかを知りたいのです。
ともかく。
では、一方向ハッシュを使用する代わりにパスワードを対称的に暗号化すると、主なリスクは何になるでしょうか?
- ユーザーになりすます？いいえ、私はすでにそのリスクを受け入れています。面白くありません。
- 悪の管理者？まあ、たぶん...しかし、繰り返しになりますが、誰かが別のユーザーになりすますことができるかどうかは気にしません。それは、内部であろうとなかろうと...とにかく、悪意のある管理者は何があってもあなたのパスワードを取得します-管理者が悪くなったら、とにかくゲームオーバーです.
- 提起されたもう 1 つの問題は、ID が実際には複数のシステム間で共有されていることです。ああ！これは非常に興味深いリスクであり、詳しく調べる必要があります。共有されるのは実際のIDではなく、証明または認証資格情報で
あると主張することから始めましょう。さて、共有パスワードは事実上別のシステム（たとえば、私の銀行口座やGmail）への入り口を許可するので、これは事実上同じIDであるため、単なるセマンティクスです...そうではないことを除いて. このシナリオでは、ID は各システムによって個別に管理されます (ただし、OAuth などのサード パーティの ID システムが存在する場合がありますが、このシステムでは ID とは別のものです。これについては後で詳しく説明します)。
このように、ここでのリスクの中心的なポイントは、ユーザーが自分の (同じ) パスワードを複数の異なるシステムに喜んで入力することです。そして今、私 (管理者) または私のサイトの他のハッカーは、エルマおばさんのパスワードにアクセスして、核ミサイルサイト。
うーん。
ここで何かおかしいと思いませんか？
そうすべき。
核ミサイルシステムを保護することは私の責任ではないという事実から始めましょう。では、誰の責任ですか？うーん... 核ミサイルシステムはどうですか？当たり前。
第二に、誰かのパスワード (安全なサイトとそうでないサイトの間で同じパスワードを繰り返し使用することが知られている人) のパスワードを盗もうとした場合、わざわざあなたのサイトをハッキングする必要があるでしょうか? または、対称暗号化に苦労していますか? Goshdarnitall、私は自分の簡単なウェブサイトを立ち上げるだけで、ユーザーがサインアップして、彼らが望むものについての非常に重要なニュースを受け取ることができます... Puffo Presto、私は彼らのパスワードを「盗みました」。
はい、ユーザー教育は常に私たちを苦しめるために戻ってきますね。
そして、それについてあなたができることは何もありません...あなたがあなたのサイトで彼らのパスワードをハッシュし、TSAが考えることができる他のすべてをしたとしても、あなたは彼らのパスワードに保護を追加しました.出くわすすべてのサイトに無差別にパスワードを貼り付けます。気にしないでください。
別の言い方をすれば、あなたは彼らのパスワードを所有していないので、あなたのように振る舞おうとするのをやめてください.
セキュリティ専門家の皆様、老婦人が Wendy's に「リスクはどこにあるのですか?」と尋ねたものです。
上記で提起されたいくつかの問題への回答として、別のいくつかのポイント：
- CWE は法律でも規制でもなく、標準でもありません。これは、一般的な弱点の集まりです。つまり、「ベスト プラクティス」の逆です。
- 共有アイデンティティの問題は実際の問題ですが、ここでは否定論者によって誤解されています (または誤って伝えられています)。これは ID を共有すること自体 (!) の問題であり、価値の低いシステムでパスワードを解読することの問題ではありません。価値の低いシステムと価値の高いシステムの間でパスワードを共有している場合、問題はすでにそこにあります。
- ところで、前のポイントは実際には、これらの価値の低いシステムと価値の高い銀行システムの両方に対して OAuth などを使用してAGAINSTを指すことになります。
- これは単なる例であることは承知していますが、(悲しいことに) FBI システムは実際には最も安全なシステムではありません。猫のブログのサーバーとはまったく異なりますが、より安全な銀行の一部を上回っているわけでもありません.
- 暗号化キーの分割知識、または二重管理は、軍隊だけで発生するわけではありません。実際、PCI-DSS は現在、基本的にすべての商人からこれを要求しているため、それほど遠くない (価値がそれを正当化する場合)。
- このような質問が、開発者という職業の見栄えを悪くしていると不満を漏らしているすべての人へ: セキュリティの専門家の見栄えをさらに悪くするのは、このような回答です。繰り返しになりますが、ビジネスに焦点を当てたリスク分析が必要です。そうしないと、役に立たなくなります。間違っていることに加えて。
- これが、通常の開発者を採用して、別の考え方や正しいトレードオフを探すためのトレーニングをせずに、セキュリティの責任を彼に任せるのは良い考えではない理由だと思います。気分を害することはありませんが、ここにいる皆さん、私は大賛成です - しかし、より多くのトレーニングが必要です。
うわー。なんと長い投稿...
しかし、元の質問に答えるには、@Shane:
- 適切な方法をお客様に説明します。
- 彼がまだ主張する場合は、もう少し説明し、主張し、議論してください。必要に応じて、かんしゃくを投げます。
- ビジネスリスクを彼に説明してください。詳細は良好で、数値も良好で、通常はライブ デモが最適です。
- 彼がまだ主張し、正当なビジネス上の理由を提示している場合は、あなたが判断を下す時が来ました:
このサイトは価値が低いか価値がないか? それは本当に有効なビジネスケースですか？それはあなたにとって十分ですか？正当なビジネス上の理由よりも重要な、他に考慮できるリスクはありますか? (そしてもちろん、クライアントは悪意のあるサイトではありませんが、当然のことです)。
もしそうなら、ただ先に進んでください。必要なプロセスを導入するための努力、摩擦、および使用の損失 (この仮想的な状況では) に値するものではありません。他の決定 (この状況でも) は、悪いトレードオフです。
つまり、結論と実際の答え - 単純な対称アルゴリズムで暗号化し、強力な ACL とできれば DPAPI などで暗号化キーを保護し、それを文書化し、クライアント (その決定を行うのに十分な上級者) にサインオフしてもらいます。それ。