このシナリオは、パスワードをプレーンテキストで保存しないというルールの例外ですか？
私は教授のためにフルスタックのWebアプリケーションを作成しています。彼の要求に応じて、パスワードとユーザー名はプログラムで生成され、学生が変更したりリセットしたりすることはできません。 （パスワードを忘れた場合は、それを調べることができる教授に尋ねてください。）この厳密に制御されたシステムは、データベースへのパスワードの保存に関する通常のベストプラクティスをすべて行う必要をなくしますか？
関連性がある場合、アプリには、学生の識別情報（名前、性別など）とユーザー名およびパスワードの間の関連付けや識別子は含まれていません。
編集1：多くの回答をありがとうございます。私はこのキャリアへの伝統的なルートをとらず、おそらくあなたにとって基本的なように見える私の知識のいくつかの穴を持っているので、これは私にとって非常に役に立ちます。明確化のポイントは次のとおりです。
- 私は初めてのフリーランスプロジェクトのフリーランサーであり、クライアント/顧客は教授です。私は彼の生徒ではありません。これは課題ではありません。
- 私の仕事は、非常に古く、ソースコードが失われている既存のアプリケーションを置き換えることです。
- このアプリケーションは、米国のさまざまな学校の複数の教授が教えるクラスで使用されています。教科書のように、コンテンツの多くは静的です。ただし、教授が作成したアンケート/器具を使用して、選択した実際の例（つまり、自分や他の人に関する情報ではない情報）に関連するコースのトピックを理解することもできます。
- ユーザー名/パスワードを設定することでの最初の目標は、ユーザーを特定して、コンテンツへのアクセスの有効期限を強制し、権限を制御できるようにすることでした。学生に加えて、管理者ユーザー（作成したユーザー名/パスワードのリストを表示してさらに作成できるダッシュボードを持っている）とスーパー管理者（管理者ができることに加えて、行う、他の管理者ユーザーを作成できます）。
- ユーザー名とログインのパスを開始した主な理由は、それが古いアプリが持っていたものだからです。しかし、古いアプリには学生情報が（たくさん！）保存されていました。担当の教授は [〜＃〜] ferpa [〜＃〜] の法則に違反することを望まないため、そこで要件を変更しました。
- 教授は別のユーザー名/パスワードセットを作成し、必要に応じて現在のクラスに追加できます。しかし、彼らは現在強制されていません。 （元のパスワードを教えてもらえます。）リストに「パスワードのリセット」ボタンが必要かどうかを尋ねたところ、これは教授の決定でした。
これは、安全でない認証の本当に良い例であり、サイトが危険にさらされている場合、個人を特定することは不可能であることを根拠として正当化されています。その場合、なぜユーザー名が必要なのでしょうか。各生徒に秘密のアクセスコードを与えるだけです。
ここにいくつかの欠陥があります：
違反の規模-クリアテキストのユーザー名/パスワードリストを入手したユーザーによってサイト全体が侵害されます。このリストには、教授が適切な学生にユーザー名/パスワードを提供できるように、いくつかの識別情報が含まれている必要があります。これで、その学生に関するデータまたはその学生に固有のデータを含むアプリケーションと、最初に各ユーザー名が誰であるかを通知し、次にそのサイトにログインするためのパスワードを提供して、そのユーザーのデータを表示できるIDファイルができました。
Authentication-認証の重要なポイントは、ウェブページのリクエストを行う人の身元を確実に認証することです。実在の人物だけが秘密のパスワードを知っているため、ユーザー名/パスワードは有効です。この教授のシナリオでは、少なくとも2人がすべてのユーザー名とパスワードを知っているため、これは当てはまりません。
侵害された資格情報-誰かの資格情報が危険にさらされるとどうなりますか？彼らはどのようにすぐにそれらを取り消すのですか？彼らはどのように新しいものを手に入れますか？教授は1人の学生の新しいパスワードを作成できますか、それとも教授は最初のプロセスを繰り返して全員の新しいパスワードを作成する必要がありますか？
「パスワードをプレーンテキストで保存しない」はルールではありません。これはベストプラクティスであり、パスワード保護の単純な実装に関する一般的なセキュリティ違反に基づいています。
その意味で、質問：
このシナリオは、パスワードをプレーンテキストで保存しないというルールの例外ですか？
誰も何も強制していないという意味で本当に答えはありません。私たちが議論できるのは、前述の慣行に従うprosとconsだけです。
おそらくあなたの質問をフレーズするより良い方法は：
このシナリオは、パスワードをプレーンテキストで保存するときに通常発生する問題の影響を受けますか？
そしてそのために、答えがイエスであることがより明確になると思います。セキュリティは、パスワードファイルにアクセスしたり、システム（教授）とクライアント（学生）の間の通信を持っているユーザーによって侵害されます。
個人データは承認なしに共有され、なりすましの試みが行われる可能性があります。大学のシナリオでは、攻撃者は学業に害を及ぼす可能性のあるツールにアクセスしたり、電子メールプロバイダーや銀行口座などの別のシステムを攻撃するのに十分な情報を入手したりする可能性があります。
要するに：いいえ
パスワードを忘れた場合は、それを調べることができる教授に尋ねます
質問に、ここで安全な認証ガイドラインを無視する本当の理由はありません。多くの（あまりに多くの）人々は、侵害は他人にのみ起こり、「私にとっては問題がなく、ここまで物事を確保する必要はない」と思っていますが、残念ながらそうではありません。これは私があなたがこの教授を提案できると私が提案するものです：
- 認証は標準的な方法で行われます。生成されたパスワードのハッシュのみが保存および比較されます
- パスワードは教授のみがリセットできます。これは、両側のユーザーエクスペリエンスに関して上記で引用したものと同等です（リセットされたパスワードVS失われたものをベースで検索します。最初の方が私にはさらに簡単に見えます）。
- 教授のみにオプションを提供するための開発コストは非常に小さいです。
教授が生成されたパスワードのリストをファイルに保存したい場合、それは彼/彼女の問題ですが、問題が発生してもそれはあなたの責任ではありません。
いいえ、しかしプレーンテキストファイルはおそらくあなたの心配事の最も少ないものです。
したがって、次のように答えてください。
1）学生のID、氏名、住所、または大学が個人識別情報（PII）で検討しているその他の情報など、個々の学生を一意に識別できる情報はありますか？
2）このシステムは、心理テストなど、学生から情報を収集していますか？
3）このシステムには、学生の評価に使用される個々のテスト/クイズのスコアが保存されますか？
上記のいずれかに「はい」と答えた場合は、教授ではなく、大学の方針に従う必要があります。
＃1や＃3を多分答えたとしても、すぐに情報セキュリティの担当者を探す必要があります。このシステムが行っていることはすべて、彼の承認が必要です。
＃2に「はい」または「あるいはその両方」と答えた場合、システムは、治験審査委員会（IRB）によってレビューされる可能性があり、HIPPAと人間の被験者の保護に準拠している必要があります（HIPPAは医療プライバシーに関する米国の規制であり、はい、心理テスト/調査/スクリーニングは社会学と同様に重要です...-そしてEUプライバシー法はより厳格であり、遵守するのがより困難です）。 HIPPAを使用すると、法的責任を問われる場合があります。
外部の脅威に加えて、クラスの生徒はシステムをハッキングして他の生徒の成績に悪影響を及ぼす可能性があります。
結論として、コンプライアンスの問題があなたではなく彼の決定に当てはまるように、この教授からの要件の紙の証跡を維持します。
教授が忘れたパスワードを検索できる必要があるため、パスワードをプレーンテキストで保存することを避ける方法はありません。したがって、要件が100％柔軟性がないと仮定すると、これはおそらく例外としてカウントされます（ただし、他の場所での不適切なセキュリティプラクティスの結果として生じるものであり、プレーンテキストパスワードが安全であるという意味では決して例外ではありません）この状況では、割り当てられた要件を満たすための方法が他にないということだけです。
ただし、実際の問題は、そもそもプレーンテキストのパスワードストレージを必要とする周囲の手順にあります。個人的には、生徒が自分の安全でないパスワードを設定できないようにしたいという欲求は理解できましたが、教授が生徒がパスワードを変更できないようにする必要がある理由はわかりません（ただし、生徒は引き続きパスワードを新しいパスワードにリセットできるはずです）古いパスワードが侵害された場合にランダムに生成されたもの）。しかし、もっと重要な点として、ランダムに生成された新しいパスワードを作成して新しいパスワードを与える代わりに、教授がユーザーの既存のパスワードを忘れた場合に、教授がそのパスワードを取得する必要がある理由はありません（これは、「show 「現在のパスワード」から「新しいパスワードを生成」するため、教授が使用するのに余計な手間がかかりません。これを行うと、パスワードをプレーンテキストで保存する必要がなくなります（パスワードを生成してすぐに表示する一般的なケースになります）プレーンテキストバージョンは引き続き使用できますが、ハッシュバージョンのみを保存します）。
TL; DR教授の要件を満たす唯一の方法は、パスワードをプレーンテキストで保存することですが、これにより、パスワードを安全にしたり、受け入れたりすることはできません（問い合わせ先によって異なります）。より良いオプションは、「忘れたパスワードを取得する」機能を「新しいパスワードを生成する」オプションで置き換えることです。これは、ユーザーがパスワードを忘れた場合でも、教授とまったく同じように機能します。
それは本当に重要ではなく、単にそれらを保護します。
ここにいくつかの理由があります。
資格情報を保護しないことにはメリットはありません。資格情報のハッシュ化または暗号化の計算コストと、パフォーマンスまたはユーザーエクスペリエンスへの影響はわずかです。アプリケーションのこの機能が1秒あたり数千のリクエストを持つことはまずありません。何百人も。おそらく、1時間または1日あたり数握りですが、これはすべて推測です。
そのような脅威がある場合、なりすましは脅威です。教授が気にしなかったのなら問題ありません1。 セキュリティは、実際の脆弱性と関連する脆弱性に比例して実装する必要があります。教授は、彼の日常業務のいくつかのタスクを容易にするためのツールを構築することを要求した可能性があります。バーチャルキャンパスの実装を求められたとは思いません。アプリケーションが大学、学校などを対象としている場合は、契約があり、資格証明を保護することは誰にとっても非常に便利であるという結論につながる、現在の法律を遵守することを余儀なくされる可能性があります。特にあなたのために。
教授が個人的にパスワードを確認して提供したいかどうかは問題ではありません。彼は所有者として、ユーザーの入力ではなく自動生成されたこの情報を知ることを正当化しています。彼は事前の同意なしにそれらすべてを変更することを決定することさえできました！
それは教授を主要な脅威に変えますか？はい、しかしセキュリティエージェントにも。私がコメントしたように、彼は事前の合意なしに一方的にパスワードを無効にすることができるので、それは「ゲートキーパー」です。いずれにせよ、私たちは誰を判断するのですか？
ただし、これは、あなた（または他の第三者）がこの情報を知ることが正当化されているという意味ではありません。だから、それを守ってください。キーペアに基づく暗号化システムを使用できます。
知覚対現実。教授やユーザーが考えているとは、必ずしも本当にであることを意味するわけではありません-）起こります。教授にはパスワードが表示されますが、パスワードがそのように保存されているという意味ではありません。
よく知られ、文書化されているセキュリティ標準を使用できるため、複雑さは議論の余地があります。それらの多くは、私たちのお気に入りのプログラミング言語で実装されています。 AngularではAESでさえ可能です。
authenticationは必須ではないという感じがします。資格情報はユーザーを特定するのではなく、ユーザーを承認します。その場合は、@ Michael Shawの回答が示唆するように、キーまたはトークンを使用して安全で匿名のセッションを実装できますが、それらはまだ資格情報であり、保護する価値があるという事実は変わりません。
1：多分彼はこの種の脆弱性を認識していないので、彼に言及する必要があります。
データベースにパスワードを保存する場合は、データベースに直接アクセスできるユーザーを検討してください。それはどのように保護されていますか？ディスク上のデータファイルに誰がアクセスしたか。バックアップはありますか？誰がバックアップにアクセスできますか？
このデータへのアクセス権を持つすべての人が誰にでもなりすますことができても大丈夫ですか？
教授がこれを必要であると考えるようにしているという制約が何であるかをよりよく理解しようとすることをお勧めします。これが解決するはずの問題は何ですか？
たとえば、ユーザーとしてログインできるようにしたいですか？もしそうなら、なぜですか？代わりに、このソリューションが解決するはずの問題に対処する別の方法を考え出すことは可能でしょうか？たとえば、学生がWebベースのIDEを使用するコースがあり、管理者がセッションを引き継ぐことができるモードがあります。これは、回避できないように見えるエラーの混乱。
または、データをプルしたい可能性があり、それを行うにはパスワードが必要だと考えていますか？上で述べたように、個人のパスワードでログインするよりもデータをプルする方がはるかに良い方法があります。
あなたが指摘するかもしれない一つのことは、これが等級付けの目的に使用されている場合、学生はデータが教授または他の誰かによって変更されたと主張することができるということです。
ベストプラクティスを適用する必要性がなくなるわけではありませんが、機会がなくなるようです。あなたが言うように、ユーザーが変更できないパスワードをアプリが自動的に割り当て、ユーザーに関する個人識別情報が含まれていない場合、おそらくアプリケーションの範囲外のリスクにユーザーをさらすことはないでしょう。
私が尋ねる質問は：
セキュリティアプローチがこのように指定されたのはなぜですか？簡単にするために？
ベストプラクティスモデルを使用してみませんか？複雑すぎると感じましたか？
教授がアクセス権を持つユーザーを制御したい場合、より良いアプローチは、ユーザーアカウントの作成時にワンタイムパスワードを生成し、ユーザーがを使用してログインに成功したら自分で選択したパスワードを設定することです。ワンタイムパスワード。すべての場合において、パスワードはソルト/ハッシュ化する必要があります。忘れたパスワードを処理するには、新しいワンタイムパスワードを生成し、強制変更プロセスを繰り返すだけです。
それが意味のあるデータを持たない短期間のアプリケーション（おそらく概念実証のみ？）である場合、要求されたアプローチは単純化のために正当化される可能性がありますが、重要なライフスパンを持つ深刻なアプリケーションである場合は、最良の選択将来の悲しみを避けるためには、正しい方法でそれを行うことです。