後で平文を取得するために、ユーザーのパスワード記憶域を倫理的にアプローチするにはどうすればよいですか。
ますます多くのWebサイトやWebアプリケーションを構築し続けているうちに、ユーザーに問題がある場合にパスワードを取得できるようにユーザーのパスワードを保存するように求められることがよくあります。私はこのやり方と激しく闘うことができて、実際のパスワードを保存せずにパスワードのリセットと管理支援を可能にするために多くの「追加の」プログラミングを行います。
私がそれに対抗できない（または勝つことができない）場合は、少なくともパスワードが平文としてデータベースに格納されないように、常に何らかの方法でパスワードを暗号化します。犯人がパスワードを解読してもそれほど問題にならないので、それは私を不快にさせます。
完璧な世界では、人々は頻繁にパスワードを更新し、多くの異なるサイトにまたがってそれらを複製することはないでしょう - 残念ながら私は同じ職場/自宅/ Eメール/銀行のパスワードを持っています。私のDBセキュリティ手順が何らかの理由で失敗した場合、私は彼らの金銭的消滅の責任者になりたくありません。
道徳的かつ倫理的に私は、たとえ彼らがはるかに少ない尊敬でそれを扱っていても、何人かのユーザーにとって、彼らの生計を守る責任があると感じます。ハッシュを塩漬けにしたり、エンコードのオプションを変えたりするためのアプローチや議論の仕方はたくさんあると確信していますが、それらを保存する必要がある場合、単一の「ベストプラクティス」はありますか？ほとんどすべての場合、私はPHPとMySQLを使用していますが、それによって仕様の処理方法に違いが生じる場合があります。
バウンティの追加情報
私はこれがあなたがしなければならないことではないということを私が知っていることを明確にしたいです、そして、ほとんどの場合そうするのを拒否するのが最善です。しかし、私はこのアプローチをとることのメリットについての講義を探しているのではありません。あなたがこのアプローチを取った場合にとるべき最良のステップを探しています。
以下のメモで、私は、ウェブサイトが、高齢者、精神障がい者、または非常に若い方を対象としているため、安全なパスワード回復手順を実行するよう求められた場合に混乱を招く可能性があると指摘しました。そのような場合、私たちはそれが単純で平凡であると思うかもしれませんが、何人かのユーザーは彼らにシステムに彼らを助けるサービス技術を持っているか、それを直接彼らに電子メールで送って/表示させました。
このようなシステムでは、ユーザーがこのレベルのアクセス支援を与えられていない場合、これらの人口統計からの消耗率がアプリケーションを妨害する可能性があるため、このような設定を念頭に置いて答えてください。
みんなのおかげで
これは多くの議論を伴う楽しい質問であり、私はそれを楽しんだ。結局のところ、私はパスワードセキュリティを保持する（プレーンテキストや回復可能なパスワードを保持する必要はない）だけでなく、私が見つけた大きな欠点なしでシステムにログインすることを可能にする答えを選びました。通常のパスワード回復.
いつものように、私は異なる理由で正解とマークしたいと思う約5つの答えがありました、しかし私は最良のものを選ばなければなりませんでした - 残りはすべて+1を得ました。みんな、ありがとう！
また、この質問に投票したり、お気に入りとしてマークしたStackコミュニティのみんなに感謝します。私は賛辞として100の得票を打つと思います、そしてこの議論が私が持っていたのと同じ懸念を持つ他の誰かを助けてくれたことを願っています。
この問題に対して別のアプローチや角度を取るのはどうですか。パスワードが平文である必要がある理由を尋ねてください。ユーザーがパスワードを取得できるようになっているのであれば、厳密に言えば、自分が設定したパスワードを取得する必要はありません。彼らに彼らが使うことができるパスワードを与えることができる必要があります。
考えてみましょう。ユーザーがパスワードを取得する必要がある場合は、忘れてしまったためです。その場合、新しいパスワードは古いものと同じくらい良いです。しかし、今日使用されている一般的なパスワードリセットメカニズムの欠点の1つは、リセット操作で生成されたパスワードが一般にランダムな文字の集まりであるため、ユーザーがコピー入力しない限り正しく入力するのが難しいことです。ペースト。それは、あまり知識のないコンピュータユーザにとっては問題になる可能性があります。
この問題を回避する1つの方法は、多かれ少なかれ自然言語のテキストである自動生成パスワードを提供することです。自然言語の文字列は、同じ長さのランダムな文字列が持つエントロピーを持っていないかもしれませんが、自動生成されたパスワードが8（または10または12）文字しか必要としないということは何もありません。いくつかのランダムな単語をつなぎ合わせて、高エントロピーの自動生成パスフレーズを取得します（それらの間にスペースを空けます。そのため、読むことができる人なら誰でも認識および入力可能です）。長さが異なる6つのランダムな単語は、10個のランダムな文字よりも正確かつ確実に入力するのがおそらく簡単であり、それらのエントロピーも高くなる可能性があります。例えば、大文字、小文字、数字、および10個の句読記号（合計72個の有効な記号）からランダムに作成された10文字のパスワードのエントロピーは、61.7ビットのエントロピーを持つことになります。 6ワードのパスフレーズ用にランダムに選択できる7776ワードの辞書（Dicewareが使用）を使用すると、パスフレーズのエントロピーは77.4ビットになります。詳しくは Diceware FAQ をご覧ください。
約77ビットのエントロピーを持つパスフレーズ：「散文フレアテーブル急性フレアを認める」
約74ビットのエントロピーを持つパスワード： "K：＆$ R ^ tt〜qkD"
私は私がフレーズをタイプすることを好むことを知っています、そしてcopy-n-pasteで、フレーズはそれほどパスワードを使用することもそれほど簡単ではありませんので、そこでの損失はありません。もちろん、あなたのウェブサイト（あるいは保護された資産が何であれ）が自動生成されたパスフレーズのために77ビットのエントロピーを必要としないなら、より少ない単語を生成してください（私はあなたのユーザーに感謝するでしょう）。
私は、パスワードで保護された資産には本当に高いレベルの価値がないという議論を理解しているので、パスワードの侵害は世界の終わりではないかもしれません。たとえば、私がさまざまなWebサイトで使用しているパスワードの80％が侵害されても、おそらく気にしません。それは素晴らしいことではありませんが、彼らが私の銀行口座に侵入するようなものではありません。しかし、多くの人が自分の銀行口座（およびおそらく国家安全保障データベース）と同じようにWebフォーラムサイトに同じパスワードを使用しているという事実を考えると、これらの「低価値」パスワードでも非パスワードとして扱うのが最善だと思います。回収可能。
誰かが大きな建物を建造するように依頼したとしましょう - バー、例えば言おう - そして以下の会話が起こります：
建築家：この建物のためには、ここ、ここ、ここに消火設備が必要です。
クライアント：いいえ、維持するには複雑すぎて費用がかかります。または裏口
建築家：サー、消防署は任意ではなく、市の消防法に従って必要です。
クライアント：私があなたに主張するように支払っているわけではありません。私が求めたことをするだけです
建築家はそれから、消防署なしでこの建物を倫理的に建設する方法を尋ねますか？
建築およびエンジニアリング業界では、会話は次のように終わる可能性が最も高いです。
建築家：この建物は非常口なしには建てられません。あなたは他のどんな資格のある専門家にでも行くことができます、そして、彼はあなたに同じことを言います。今出発します。あなたが協力する準備ができたら私に電話してください。
コンピュータプログラミングはライセンスされた職業ではないかもしれませんが、私たちの職業が土木技師や機械技師と同じ点を尊重しない理由はよく疑問に思われます。これらの職業は、ゴミ（または完全に危険な）要件を手渡されたとき、単に拒否します。彼らは、「まあ、私は最善を尽くしたが、彼は主張した、そして私は彼が言うことをしなければならない」と言うのが言い訳ではないことを知っている。彼らはその言い訳の免許を失う可能性があります。
あなたまたはあなたのクライアントが上場企業の一部であるかどうかはわかりませんが、パスワードを回復可能な形式で保存すると、さまざまな種類のセキュリティ監査に失敗する可能性があります。問題は、パスワードを回復するためにあなたのデータベースにアクセスした何人かの "ハッカー"にとってそれほど難しくないことです。 セキュリティ上の脅威の大部分は内部的なものです。不信を抱く従業員がすべてのパスワードを入力して最高入札者に販売すること。非対称暗号化を使用して秘密鍵を別のデータベースに格納しても、このシナリオを防ぐことはできません。常に誰かがプライベートデータベースにアクセスできるようになるでしょう、そしてそれは深刻なセキュリティリスクです。
パスワードを回復可能な形式で保存するための倫理的または責任ある方法はありません。ピリオド
あなたは公開鍵でパスワード+ saltを暗号化することができます。ログインの場合は、保存されている値がユーザー入力から計算された値+ saltに等しいかどうかを確認するだけです。平文でパスワードを復元する必要があるときがある場合は、秘密鍵を使用して手動または半自動で復号化できます。秘密鍵は他の場所に格納され、さらに対称的に暗号化されることがあります（その場合、パスワードを復号化するには人間の操作が必要になります）。
これは、 Windows回復エージェント の機能と同じようなものです。
- パスワードは暗号化されて保存されます
- 平文に復号化せずにログインできます
- パスワードは平文に復元できますが、秘密鍵を使用する場合に限り、システムの外部に保存できます（必要に応じて銀行の金庫に保管できます）。
あきらめてはいけない。あなたのクライアントを説得するのに使用できる武器は否認不可です。何らかの方法でユーザーのパスワードを再構築できるのであれば、彼らのクライアントには法的な否認防止のメカニズムを与えています。サプライヤは、パスワードを再構築していないことを証明し、自分で取引を行うことができます。パスワードが暗号文ではなくダイジェストとして正しく保存されている場合、これは不可能です。エンドクライアントが自分でトランザクションを実行したか、または自分の注意義務に違反しました。パスワード。どちらの場合も責任は彼にまっすぐに残ります。私はそれが数億ドルに達するケースに取り組んできました。あなたが誤解したくないものではありません。
後で平文を取得するためにパスワードを倫理的に保存することはできません。それはそれと同じくらい簡単です。 Jon Skeetでさえ、後で平文を取得するためにパスワードを倫理的に保存することはできません。あなたのユーザがどうにかして平文でパスワードを検索できるなら、潜在的にあなたのコードにセキュリティの脆弱性を見つけたハッカーもそうすることができます。これは、1人のユーザーのパスワードが危険にさらされているだけではなく、すべてのユーザーのパスワードを意味します。
あなたのクライアントがそれに問題を抱えているならば、回復可能なようにパスワードを保存することは法律違反です。いずれにせよ、ここ英国では、1998年データ保護法（特に、Schedule 1、Part II、Paragraph 9）は、データ管理者に個人データの安全を守るために適切な技術的措置を講じることを求めています。データが危険にさらされた場合に発生する可能性がある害 - サイト間でパスワードを共有するユーザーにとってはかなりの可能性があります。それでも問題であるという事実をよく理解できない場合は、 this のように、現実的な例をいくつか挙げてください。
ユーザーがログインを回復できるようにする最も簡単な方法は、自動的にログインして新しいパスワードを選択できるページに直接アクセスできるワンタイムリンクを電子メールで送信することです。プロトタイプを作成して、それらを実際に見せてみましょう。
この件に関して私が書いたブログ記事がいくつかあります。
- http://jamesmckay.net/2009/09/if-you-are-saving-passwords-in-clear-text-you-are-probably-break-the-law/
- http://jamesmckay.net/2008/06/easy-login-recovery-without-compromising-security/
更新：現在、ユーザーのパスワードを正しく保護できない企業に対する訴訟や訴追が始まっています。例： LinkedInは500万ドルの集団訴訟で殴打しました 。 ソニーはPlayStationのデータハック に対して£250,000の罰金を科した。正しく思い出してみると、LinkedInは実際にはユーザーのパスワードを暗号化していましたが、使用していた暗号化は弱すぎて効果的ではありませんでした。
この部分を読んだ後：
以下のメモで、私は、ウェブサイトが、高齢者、精神障がい者、または非常に若い方を対象としているため、安全なパスワード回復手順を実行するよう求められた場合に混乱を招く可能性があると指摘しました。そのような場合、私たちはそれが単純で平凡であると思うかもしれませんが、何人かのユーザーは彼らにシステムに彼らを助けるサービス技術を持っているか、それを直接彼らに電子メールで送って/表示させました。
このようなシステムでは、ユーザーがこのレベルのアクセス支援を与えられていない場合、これらの人口統計からの消耗率がアプリケーションを妨害する可能性があるため、このような設定を念頭に置いて答えてください。
これらの要件のいずれかが取得可能なパスワードシステムを要求しているのかどうか私は疑問に思います。例：おばさんのMabelが電話をかけて、「あなたのインターネットプログラムは機能していません、私のパスワードを知りません」と言います。 「OK」と顧客サービスドローンが言っています「詳細をいくつか確認してから新しいパスワードを入力します。そのパスワードをそのまま使用するか、覚えやすいパスワードに変更したいのです。」
その後、パスワードのリセットがいつ行われたかを認識し、「新しいパスワードを保持するか、または新しいパスワードを選択しますか」というメッセージを表示するようにシステムが設定されます。
古いパスワードを言われるよりも、PCに精通していない人にとって、これはどうして悪いのでしょうか。また、カスタマーサービス担当者がいたずらをする可能性がある一方で、データベース自体が侵害された場合に備えてはるかに安全です。
私の提案で悪いところをコメントしてください、そして私はあなたが最初に望んでいたことを実際にする解決策を提案します。
Michael BrooksはCWE-257についてかなり声を上げています - あなたがどんな方法を使っても、あなた（管理者）はまだパスワードを回復できるという事実。では、これらのオプションはどうでしょうか。
- でパスワードを暗号化する 他の人の 公開鍵 - いくつかの外部機関そのようにしてあなたはそれを個人的に再構築することはできません、そしてユーザーはその外部の権威に行き、彼らのパスワードを回復させることを求めなければならないでしょう。
- 2番目のパスフレーズから生成されたキーを使用してパスワードを暗号化します。この暗号化をクライアント側で行い、平文のままサーバーに送信することは絶対にしないでください。次に、回復するには、入力からキーを再生成して、復号化クライアント側をもう一度実行します。確かに、このアプローチは基本的に2番目のパスワードを使用していますが、あなたはいつでもそれを書き留めるように言うか、または古いセキュリティ問題のアプローチを使用することができます。
私は1.がより良い選択だと思います。クライアントの会社内の誰かが秘密鍵を保持するように指定できるからです。パスワードを暗号化して内部の第三者に提供することで、パスワードを解読して推測できるようにしてセキュリティを強化することもできます。それ。これらの文字をユーザーに渡すと、おそらくそれが何であるかを思い出すでしょう。
この質問に対するユーザーのセキュリティ上の懸念については多くの議論がありましたが、利点について言及したいと思います。これまでのところ、正当な利益の1つは、システムに保存された回復可能なパスワードを持つことについて言及していません。このことを考慮：
- ユーザーは、パスワードを電子メールで送信することで利益を得ますか？いいえ。1回限りのパスワードリセットリンクの恩恵を受けます。これにより、will覚えているパスワードを選択できるようになります。
- ユーザーは画面にパスワードを表示することで恩恵を受けますか？いいえ、上記と同じ理由で。新しいパスワードを選択する必要があります。
- サポート担当者がユーザーにパスワードを話すことは、ユーザーにとって有益ですか？いいえ。繰り返しますが、サポート担当者がパスワードに対するユーザーのリクエストが適切に認証されたと判断した場合、新しいパスワードとパスワードを変更する機会が与えられることはユーザーの利益になります。さらに、電話によるサポートは自動パスワードリセットよりもコストがかかるため、会社にとってもメリットはありません。
回復可能なパスワードから利益を得ることができるのは、悪意があるか、サードパーティのパスワード交換を必要とする貧弱なAPIのサポーターだけであるようです（前述のAPIを使用しないでください！）。おそらく、回復可能なパスワードを保存することで会社は利益を得ず、負債のみを得るということをクライアントに正直に述べることで、あなたは議論に勝つことができるでしょう。
これらのタイプのリクエストの行を読むと、クライアントがパスワードの管理方法を理解していないか、実際にはまったく気にしていないことがわかります。彼らが本当に望んでいるのは、ユーザーにとってそれほど難しくないauthentication systemです。そのため、回復可能なパスワードを実際に望んでいないことを伝えるだけでなく、特に銀行などの高いセキュリティレベルが必要ない場合は、認証プロセスの痛みを軽減する方法を提供する必要があります。
- ユーザーがユーザー名にメールアドレスを使用できるようにします。ユーザーが自分のユーザー名を忘れるケースは数え切れないほどありますが、メールアドレスを忘れるケースはほとんどありません。
- OpenIDを提供し、ユーザーの物忘れの費用を第三者に支払わせます。
- パスワードの制限を緩和します。 「特殊文字を使用できない」、「パスワードが長すぎる」、「パスワードを開始する必要がある」などの役に立たない要件のために一部のWebサイトで優先パスワードが許可されない場合、私たちはすべて非常に悩まされていると確信しています手紙で。」また、使いやすさがパスワードの強度よりも大きな懸念事項である場合は、短いパスワードを許可するか、文字クラスを混在させる必要がないことで、愚かな要件さえ緩和することができます。制限が緩和されると、ユーザーは忘れないパスワードを使用する可能性が高くなります。
- パスワードを期限切れにしないでください。
- ユーザーが古いパスワードを再利用できるようにします。
- ユーザーが自分のパスワードリセットの質問を選択できるようにします。
しかし、何らかの理由で（そして理由を教えてください）really、really、really回復可能なパスワードが必要な場合、ユーザーを保護することができますパスワードベースでない認証システムを提供することにより、他のオンラインアカウントを危険にさらす可能性があります。ユーザーはすでにユーザー名/パスワードシステムに精通しており、十分に機能するソリューションであるため、これは最後の手段になりますが、パスワードに代わる創造的な代替手段がたくさんあります。
- ユーザーが数字のピンを選択できるようにします。できれば4桁ではなく、できればブルートフォース攻撃から保護されている場合に限ります。
- ユーザーに、答えを知っている、決して変わらない、常に覚えている、他の人が気にしないという短い答えの質問を選択してもらいます。
- ユーザーにユーザー名を入力してもらい、推測から保護するために十分な順列で覚えやすい形状を描画します（G1が電話をロック解除するためにこれを行う方法の this nifty photo を参照）。
- 子供向けのWebサイトでは、ユーザー名（IDアイコンのようなもの）に基づいてファジークリーチャーを自動生成し、ユーザーにクリーチャーに秘密の名前を付けるように依頼できます。その後、ログインするようにクリーチャーの秘密の名前を入力するように求められます。
中途半端な家はどうですか。
強力な暗号化でパスワードを保存し、リセットを有効にしないでください。
パスワードをリセットする代わりに、ワンタイムパスワード（最初のログオンが発生したらすぐに変更する必要があります）の送信を許可します。その後、ユーザーが希望するパスワードに変更してください（選択した場合は前のパスワード）。
パスワードをリセットするための安全なメカニズムとしてこれを「売る」ことができます。
ユーザーに元のパスワードの取得を許可する唯一の方法は、ユーザー自身の公開鍵で暗号化することです。そのユーザーだけがパスワードを復号化できます。
したがって、手順は次のようになります。
- ユーザーはまだパスワードを設定せずに（もちろんSSLを介して）あなたのサイトに登録します。自動的にログインするか、一時パスワードを入力してください。
- あなたは将来のパスワード検索のために彼らの公開PGPキーを保存することを申し出ます。
- 彼らはPGPの公開鍵をアップロードします。
- あなたは彼らに新しいパスワードを設定するように頼みます。
- 彼らは自分のパスワードを送信します。
- あなたは利用可能な最善のパスワードハッシュアルゴリズム（例えばbcrypt）を使ってパスワードをハッシュします。次回のログイン確認時に使用してください。
- あなたは公開鍵でパスワードを暗号化し、それを別に保存します。
ユーザーが自分のパスワードを要求した場合は、暗号化された（ハッシュされていない）パスワードで応答します。ユーザーが将来自分のパスワードを取得できないようにしたい場合（ユーザーがパスワードをサービスによって生成されたものにリセットすることしかできない場合）、ステップ3と7はスキップできます。
私があなたがあなた自身に尋ねるべきである本当の質問がそれであると思います：「どうすれば私は人々を説得することでよりよくなることができますか？」
私は同じ問題を抱えています。そして同じように、誰かが私のシステムをハックしたのは "if"の問題ではなく "when"の問題であるといつも私は思います。
クレジットカードやパスワードなどの回復可能な機密情報を保存する必要があるWebサイトを作成する必要がある場合は、次のようにします。
- openssl_encrypt（文字列$ data、文字列$ method、文字列$ password）で暗号化します。
- PHPマニュアル 。
- data arg：
- 機密情報（ユーザーパスワードなど）
- 必要に応じてシリアル化します。情報が複数の機密情報のようなデータの配列である場合
- password arg：ユーザーだけが知っている情報を使用します。
- ユーザーナンバープレート
- 社会保障番号
- ユーザーの電話番号
- ユーザーのマザーネーム
- 登録時に電子メールおよび/またはSMSによって送信されたランダムな文字列
- メソッドarg：
- "aes-256-cbc"のような1つの暗号化方法を選択してください
- NEVERは、データベースの "password"引数で使用されている情報（またはシステム内の任意の場所）を格納します。
このデータを回収する必要があるときは、単に "openssl_decrypt（）"関数を使用してユーザーに答えを尋ねてください。例：「パスワードを受け取るには、次の質問に答えてください：あなたの携帯電話番号は何ですか？」
PS 1：データベースに保存されているデータをパスワードとして使わない。ユーザーの携帯電話番号を保存する必要がある場合は、この情報を使用してデータをエンコードしないでください。ユーザーだけが知っている情報、または親戚以外の誰かが知りにくい情報を常に使用してください。
PS 2：「ワンクリックで購入する」のようなクレジットカード情報のために、私がするのはログインパスワードを使うことです。このパスワードはデータベース（sha1、md5など）にハッシュされますが、ログイン時にプレーンテキストのパスワードをセッションまたは非永続的（つまりメモリ内）の安全なCookieに格納します。この平文のパスワードはデータベースに保存されることはなく、実際には常にメモリに保存され、セクションの最後で破棄されます。ユーザーが「ワンクリック購入」ボタンをクリックすると、システムはこのパスワードを使用します。ユーザーがfacebookやTwitterなどのサービスでログインしている場合、購入時にパスワードを再入力するか（クリックしても完全ではない）、ユーザーがログインしたサービスのデータを使用します（FacebookのIDのように）.
資格情報を保護することはバイナリ操作ではありません。セキュリティはすべてリスク評価に関するものであり、連続体で測定されます。セキュリティ狂信者はこのように考えることを嫌いますが、醜い真実は何も完全に安全ではないということです。厳格なパスワード要件、DNAサンプル、および網膜スキャンを使用したハッシュ化されたパスワードはより安全ですが、開発とユーザーエクスペリエンスが犠牲になります。平文のパスワードははるかに安全性が低くなりますが、実装は安価です（ただし、避けるべきです）。一日の終わりに、それは違反の費用便益分析に帰着します。保護されているデータの価値とその時間的価値に基づいてセキュリティを実装します。
誰かのパスワードが暴走した場合の費用はいくらですか？与えられたシステムにおけるなりすましのコストはいくらですか？ FBIコンピュータにとっては、そのコストは莫大になる可能性があります。ボブの5ページからなる1回限りのWebサイトでは、コストはごくわずかです。専門家は顧客にオプションを提供し、セキュリティに関しては実装の利点とリスクを説明します。これは、業界標準を遵守しなかったためにクライアントが何らかの危険にさらす可能性がある何かを要求した場合にも発生します。クライアントが特に双方向暗号化を要求する場合、私はあなたがあなたの異議を文書化することを確実にするでしょうが、それはあなたがあなたが知っている最善の方法で実装するのを止めないはずです。一日の終わりに、それはクライアントのお金です。はい、一方向ハッシュを使用することを強くお勧めしますが、それが絶対唯一の選択であり、それ以外に倫理的でないことはまったくナンセンスです。
双方向暗号化を使用してパスワードを保存している場合、セキュリティはすべてキー管理になります。 Windowsには、証明書へのアクセスを管理者アカウントおよびパスワードで制限するためのメカニズムがあります。あなたが他のプラットフォームでホスティングしているなら、あなたはあなたがそれらで利用可能なオプションを見る必要があるでしょう。他の人が示唆しているように、あなたは非対称暗号化を使うことができます。
私は、パスワードは一方向ハッシュを使用して保存する必要があることを明確に述べている法律はありません（英国のデータ保護法も）。これらの法律のいずれかにおける唯一の要件は、単純に合理的なステップがセキュリティのために行われることです。データベースへのアクセスが制限されている場合は、プレーンテキストのパスワードでもそのような制限の下で合法的に資格を得ることができます。
しかし、これはもう1つの側面を明らかにします：法的優先順位。あなたのシステムが構築されている業界を考えると、あなたが一方向ハッシュを使わなければならないと法的優先順位が示唆しているならば、それは全く異なっています。それはあなたがあなたの顧客を説得するために使う弾薬です。それを除けば、合理的なリスク評価を提供し、反対意見を文書化し、顧客の要求に応じることができる最も安全な方法でシステムを実装するための最善の提案です。
ユーザーのセキュリティ保護された質問に対する回答を暗号化キーの一部にし、セキュリティ保護された質問に対する回答をプレーンテキストとして保存しない（代わりにハッシュ）
私は生活のために多要素認証システムを実装しているので、リセット/再作成ワークフローのために一時的に1つ少ない要素でユーザーを認証しながら、パスワードをリセットまたは再構築できると考えるのは当然です。特に、いくつかの追加要因としてOTP（ワンタイムパスワード）を使用すると、推奨されるワークフローに対して時間枠が短い場合に、多くのリスクが軽減されます。私たちはスマートフォン用のソフトウェアOTPジェネレータ（ほとんどのユーザーがすでに一日中持ち歩いている）を実装し、大きな成功を収めました。商用プラグの不平が出る前に、パスワードがユーザーの認証に使用されている唯一の要素ではない場合、パスワードを簡単に取得またはリセット可能にすることに起因するリスクを減らすことができるということです。サイト間でのパスワードの再利用のシナリオでは、ユーザーが他のサイトも公開したいために元のパスワードを使用するように要求されるため、状況はまだよくないと思いますが、再構築されたパスワードは最も安全な方法（htppとhtml上の目立たない外観）。
この面白くて熱い議論に出会ったところです。もっとも驚いたのは、次の基本的な質問にはほとんど注意を払わなかったことです。
- Q1。ユーザーがプレーンテキストで保存されたパスワードにアクセスすることを主張する実際の理由は何ですか？それはなぜそれほど価値があるのでしょうか。
ユーザーが年配または若いという情報は、実際にはその質問に答えていません。しかし、顧客の懸念を正しく理解しない限り、ビジネス上の決定をどのように行うことができるでしょうか。
それがなぜ重要なのでしょうか。顧客の要求の本当の原因が使いにくいシステムである場合、正確な原因を解決すれば実際の問題は解決するでしょうか。
私はこの情報を持っていないし、それらの顧客と話すことができないので、私は推測することしかできません：それは使いやすさについてです、上記参照。
私が見たもう一つの質問は尋ねました：
- Q2。ユーザーが最初にパスワードを覚えていない場合、なぜ古いパスワードが重要なのですか？
そしてここに可能な答えがあります。猫の名前が "miaumiau"でパスワードにパスワードを忘れてしまった場合は、それが何であるかを思い出したり、 "＃zy * RW（ew"のようなものを送信したりしますか？）
もう1つの考えられる理由は、ユーザーが新しいパスワードを思いつくのは大変な作業だと考えていることです。そのため、古いパスワードを送り返してもらうと、その苦痛な作業から再び彼女を救うことになります。
その理由を理解しようとしているだけです。しかし、その理由が何であれ、それが対処されるべき理由ではなくその理由です。
ユーザーとして、私は物事をシンプルにしたい！一生懸命働きたくない！
新聞を読むためにニュースサイトにログインした場合、パスワードとして1111を入力してアクセスしたいです。
それが安全ではないことを私は知っていますが、私が誰かが私の「アカウント」にアクセスするのを気にかけていますか？はい、彼もそのニュースを読むことができます！
サイトには私の「個人情報」が保存されていますか？今日読んだニュースは？それは私の問題ではなく、サイトの問題です。サイトは認証されたユーザーに個人情報を表示しますか？それならそもそもそれを見せないで！
これは単に問題に対するユーザーの態度を示すためのものです。
要約すると、プレーンテキストのパスワードを「安全に」保存する方法（これは不可能です）は問題ではなく、顧客の実際の懸念にどのように対処するかという問題ではありません。
すみません、しかしあなたが彼らのパスワードを解読する何らかの方法がある限り、それが安全になる方法はありません。それを激しく戦ってください、そして、あなたが負けたら、CYA。
紛失したり忘れたりしたパスワードの処理
だれもパスワードを回復できないはずです。
ユーザーが自分のパスワードを忘れた場合は、少なくとも自分のユーザー名または電子メールアドレスを知っている必要があります。要求に応じて、UsersテーブルにGUIDを生成し、guidをパラメータとして含むリンクを含む電子メールをユーザーの電子メールアドレスに送信します。
リンクの背後にあるページで、パラメータguidが実際に存在することを確認し（おそらくタイムアウトロジック付きで）、ユーザーに新しいパスワードを要求します。
ホットラインヘルプユーザが必要な場合は、補助金モデルにロールを追加し、ホットラインロールが識別されたユーザとして一時的にログインできるようにします。そのようなホットラインログインをすべて記録します。たとえば、Bugzillaはそのような偽装機能を管理者に提供しています。
回復可能なパスワードを保存するという要件を単に拒否できないのであれば、これをあなたの反論としてどうでしょうか。
パスワードを正しくハッシュしてユーザーのためのリセットメカニズムを構築するか、システムから個人を特定できる情報をすべて削除することができます。メールアドレスを使ってユーザー設定を設定できますが、それだけです。 Cookieを使用して、将来の訪問に対する設定を自動的に引き出し、妥当な期間が過ぎるとデータを破棄します。
パスワードポリシーで見落とされがちな1つのオプションは、パスワードが本当に必要であるかどうかです。あなたのパスワードポリシーがする唯一のことがカスタマーサービスへの電話をかけることであるなら、多分あなたはそれを取り除くことができます。
平文のパスワードを暗号化して紛失する前に、登録時に電子メールで送信するのはどうですか？私は多くのウェブサイトがそれをするのを見ました、そして、ユーザーの電子メールからそのパスワードを得ることはあなたのサーバー/ compにそれを残すより安全です。
ユーザーは本当にパスワードを忘れたかどうかを回復する必要がありますか、または単にシステムにアクセスできるようにする必要がありますか。 ？本当に必要なのがログオン用のパスワードである場合、サポート担当者が自分のパスワードを失った人に渡すことができる新しいパスワードに古いパスワード（それが何であれ）を変更するだけのルーチンを用意しないでください。
私はまさにこれを行うシステムで作業しました。サポート担当者は、現在のパスワードが何であるかを知る方法がありませんが、それを新しい値にリセットできます。もちろん、そのようなリセットはすべてどこかに記録されるべきであり、パスワードがリセットされたことを知らせる電子メールをユーザーに送信することをお勧めします。
もう1つの可能性は、アカウントへのアクセスを許可する2つの同時パスワードを持つことです。 1つはユーザーが管理する「通常の」パスワードで、もう1つはサポートスタッフだけが知っているすべてのユーザーに共通のスケルトン/マスターキーのようなものです。そのようにして、ユーザが問題を抱えているとき、サポート担当者はマスターキーでアカウントにログインし、ユーザが自分のパスワードを何でもに変更するのを手助けすることができます。言うまでもなく、マスターキーを使用したログインはすべてシステムによってもログに記録されます。追加の対策として、マスターキーが使用されるたびに、サポート担当者の資格情報も検証できます。
- 編集 - マスターキーを持っていないことに関するコメントへの回答：私は、ユーザー以外のユーザーにユーザーのアカウントへのアクセスを許可するのは悪いことだと信じているのと同じように悪いことに同意します。あなたが質問を見るならば、全体的な前提は顧客が非常に妥協されたセキュリティ環境を要求したということです。
マスターキーは、最初に見えるほど悪くある必要はありません。私は防衛工場で働いていましたが、メインフレームのコンピュータオペレータが特定の機会に「特別なアクセス」を行う必要性を感じていました。彼らは単に特別なパスワードを封筒に入れてオペレーターの机にテープで貼り付けただけです。パスワードを使用するには（オペレータは知らない）、彼は封筒を開けなければなりませんでした。シフトが変わるたびに、シフトスーパーバイザーの仕事の1つは、封筒が開かれたかどうかを確認し、変更された場合は直ちに（別の部門によって）パスワードを変更し、新しいパスワードを新しい封筒に入れてプロセスを開始することでした。もう一度。オペレータはなぜ彼がそれを開けたのか質問され、事件は記録のために文書化されるでしょう。
これは私が設計する手順ではありませんが、うまく機能し、優れた説明責任を果たしました。すべてが記録され、見直され、さらにすべての事業者がDODの秘密の許可を得ており、私たちはいかなる虐待も受けていません。
見直しと監視のため、すべてのオペレーターは封筒を開封する特権を誤用した場合、即座に解雇され、刑事訴追の可能性があることを知っていました。
ですから、本当の答えは、信頼できる人を適切に雇い、身元調査を行い、適切な管理監督と説明責任を果たすことで、正しいことをしたいのであればと思います。
しかし、この貧しい仲間のクライアントがうまく管理できていたとしても、そもそもそのようなセキュリティが最適化されたソリューションを求めていなかったでしょうか。
この問題について私が理解していることから、サインオン/パスワードを使用してWebサイトを構築しているのであれば、サーバー上にプレーンテキストのパスワードも表示されないはずです。パスワードは、クライアントから送信される前にハッシュされ、おそらくは塩漬けにされるべきです。
平文のパスワードを見たことがないのであれば、検索の問題は生じません。
また、私は（Webから）MD5のようないくつかのアルゴリズムはもはや安全であるとは考えられないと主張します。自分で判断する方法はありませんが、検討する必要があります。
通常どおり、ユーザーのパスワードをソルトハッシュします。ユーザーをログインするときは、ユーザーのパスワード（ソルト/ハッシュ後）を両方とも許可するだけでなく、ユーザーが文字通りに入力したものも一致させることができます。
これにより、ユーザーは自分の秘密のパスワードを入力することができますが、自分のパスワードの塩漬け/ハッシュ化されたバージョンを入力することもできます。これは、誰かがデータベースから読み取るものです。
基本的には、塩漬け/ハッシュ化されたパスワードも「プレーンテキスト」パスワードにします。
あなたが考えていなかったかもしれないもう一つのオプションは電子メールによる行動を許可することです。これは少し面倒ですが、私はこれをシステムの特定の部分を表示（読み取り専用）するためにシステムの「外部」のユーザを必要とするクライアントに実装しました。例えば：
- ユーザーが登録されると、それらはフルアクセス権を持ちます（通常のWebサイトのように）。登録にはEメールを含める必要があります。
- データまたは操作が必要で、ユーザーがパスワードを覚えていない場合でも、特別な "をクリックして操作を実行できます "ボタン、通常の"送信 "ボタンのすぐ隣にあります。
- その後、要求がハイパーリンク付きで電子メールに送信され、アクションを実行するかどうかが尋ねられます。これはパスワード再設定Eメールリンクに似ていますが、パスワードを再設定する代わりにワンタイムアクションを実行します。
- 次にユーザは「はい」をクリックし、そしてそれはデータが示されるべきであること、またはアクションが実行されるべきであること、データが明らかにされるべきであることなどを確認する。
あなたがコメントで述べたように、これは電子メールが危殆化した場合にはうまくいきませんが、パスワードをリセットしたくないという@joachimのコメントを扱っています。最終的には、パスワードのリセットを使用する必要がありますが、必要に応じて、より都合の良いときに、または管理者や友人の支援を得て、パスワードをリセットすることができます。
この解決策のひねりは、第三者の信頼できる管理者にアクション要求を送信することです。これは、高齢者、精神障害者、非常に若い人、または他の方法で混乱しているユーザの場合に最も効果的になります。もちろん、これは彼らの行動をサポートするためにこれらの人々のための信頼できる管理者を必要とします。
スタンドアロンサーバーでDBを開き、この機能を必要とする各Webサーバーへの暗号化されたリモート接続を行います。
リレーショナルDBである必要はなく、テーブルや行の代わりにフォルダやファイルを使用した、FTPアクセスが可能なファイルシステムでもかまいません。
可能であればWebサーバーに書き込み専用の権限を与えます。
普通の人がするのと同じように、パスワードの取得不可能な暗号化をサイトのDBに保存しましょう（ "pass-a"と呼びましょう）。
新しいユーザー（またはパスワードの変更）ごとにパスワードのプレーンコピーをリモートDBに保存します。このパスワードの複合キーとして、サーバーのID、ユーザーのID、および「pass-a」を使用します。あなたは、夜間により良く眠るために、パスワードに双方向の暗号化を使うことさえできます。
誰かがパスワードとそのコンテキスト（サイトID +ユーザーID + "pass-a"）の両方を取得するためには、次の手順を実行する必要があります。
- webサイトのDBをハックして（ "pass-a"、user id）ペアを取得します。
- 設定ファイルからウェブサイトのIDを取得する
- リモートパスワードデータベースを見つけてハッキングします。
あなたはパスワード検索サービスへのアクセスを管理することができ（安全なWebサービスとしてのみ公開し、1日に一定量のパスワード検索のみを許可し、手動で行うなど）、さらにこの "特別なセキュリティ取り決め"に追加料金を請求できます。
パスワード検索DBサーバーは、多くの機能を果たさず、より安全にすることができるので、かなり隠されています（許可、プロセス、およびサービスを厳密に調整できます）。
結局のところ、あなたはその作業をハッカーにとって難しくします。どのサーバーでもセキュリティが侵害される可能性は同じですが、意味のあるデータ（アカウントとパスワードの一致）を収集するのは困難です。