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