クライアントがパスワードを取得する機能を必要とする場合はどうなりますか？
私は現在、仕事でアプリケーションを継承していますが、残念なことに、データベースに格納されているユーザーパスワードは社内の暗号化機能を使用して暗号化されています。
したがって、誰かが実際に行う必要があるのは、ユーザーテーブルをコピーして暗号化アセンブリ（データベースの本番環境へのアクセス権を持つユーザー）をコピーすることだけです。そうすれば、100,000の電子メールアドレスと潜在的なパスワードにアクセスできます。
私はなぜこれが良い考えではないのかをビジネスに説明しようとしていますが、セキュリティの概念は技術的にそれほど気にされていないため（政府向け）、彼らの頭を越えているようです。さらに、管理ユーザーがユーザーのパスワードを取得してログインし、必要なことを実行するために、アプリケーション内に実際に既存の機能があります。
したがって、彼らはセキュリティへの影響を理解していません。また、より強力なセキュリティポリシー（パスワードをハッシュして簡単に取得できないようにする）を実装するには、それらの既存の機能を削除する必要があります。
私は何をすべきか？もともとパスワードシステムを構築していなかったので、何か問題があったとしても非難されるわけではありません。一方、私はそれについて気分が悪く、10万件の潜在的な電子メールログオンにアクセスしたくありません。
安全な方法で必要な機能を実装します。別のユーザーとしてログインする管理者は、ユーザーのパスワードを知らなくても実装できます。彼らは自分自身としてログインし、「アイデンティティの変更」機能を利用できます。
パスワードデータベースの保護はビジネス上の問題ではなく、技術的な問題です。そうしないのはバグです。ビジネスがセキュリティを機能のトレードオフとして考える場合、セキュリティは失われます。このように考える理由を彼らに与えるべきではありません。
あなたは彼らが本当にそうすることを彼らに納得させる必要がありますnot彼らのサーバーが侵入された場合の民事責任が必要です。また、彼らが過失であることを認識している情報に基づくユーザーベースからの反発も必要ありません。
一方の当事者が間違っていて、もう一方の当事者が正しいという明確なケースがある場合があります。これはその時の一つです。
ソニーに何が起こったかを見てください。また、私たちのサイトは最近ハッキングされました。そして、それが未軽減の災害になるのを妨げた理由の1つは、（比較的）優れた一方向ハッシュ関数（SHA512）を使用したことです。それ以来、ブルートフォース攻撃や辞書攻撃を防ぐため（または少なくとも攻撃不可能にするため）、bcryptに切り替えました。他に良心的なものは何もありません。
事実：人々は多くのサイトで同じパスワードを使用しています
上司はおそらく、人々がすべての種類のサービス（バンキングやFacebookなどを含む）に単一のパスワード（またはそれらの非常に限られたセット）を使用することが多いことを理解していません。ユーザーがシステムでパスワードを変更できる場合、他の場所と同じパスワードを使用している可能性が高いです。
上司がこのパスワードアクセスに問題がないと考えている場合は、この事実を伝えておく必要があります。アプリが壁の向こう側にあり、パブリックにアクセスできない場合でも、他のオンラインサービスにセキュリティ上の脅威をもたらす可能性があります。ユーザー名（特にメールの場合）は、かなり簡単に推測できます。上司のFacebookアカウントにログインして壁に何かを置くのがどれほどおもしろいか想像できません。
ユーザーパスワードは常に、限られた数の人しかアクセスできない最上位のプライバシー/機密情報として扱われるべきです。このような揮発性の情報を保存しないことをお勧めします。また、その場合でも、この情報へのアクセスを1つずつ許可する必要があります。複数のキーでのみ開くことができる非常に安全な金庫から機密書類を入手するようなものです。したがって、誰がいつアクセスできるかがわかります。
アカウントの委任を実装する方法
アプリケーションでのアカウントの委任は別の方法で行う必要があります。
- 管理者は自分自身としてログインしてから、
- どちらか（特権ユーザーであるため）
- 入力するserNameまたは
- リストから特定のユーザーを選択してログインします
serName + Passwordの組み合わせでログインすることは絶対にしないでください。
委任されたログオンを可能にするために新しい画面を開発する必要があることは事実ですが、それでもまだです。
委任されたログオンの方が優れているのはなぜですか？
また、一部のユーザーに代わって管理者が何らかのアクションを実行したことを明確にする追加機能を提供することもできます（管理者は神として機能し、だれでもログインし、害を及ぼす可能性のある行為を行っている可能性があるため、現時点ではわかりません）実際の従業員の評判）。
人々は間違いを犯すことに同意する必要があります。管理者も人間です。そして、彼らが誰かのために間違いを犯した場合、彼らは彼らのせいにしようとします。私はそれについて100％確信しています。これにより、管理者以外のユーザーの安全性が高まり、実際の評判が他の人の過ちの影響を受けなくなります。
アプリケーションが何をするかについては言及しません。保護が必要なID盗難情報が満載のパスポートアプリケーションの場合、最大限の保護に値します。しかし、「自宅までのルートでの交通事故を教えて」の場合、パスワード違反の結果はどうなりますか？私が書いたいくつかのシステムにはパスワードさえありません-あなたは単にあなたの電子メールまたは学生番号または人々がお互いについてよく知っている他の識別子を入力するだけであり、システムの所有者は使いやすさとロックできないことを重視しています人々が互いになりすましている場合、プライバシー侵害の可能性を回避します。私も問題ありません。たとえば、会議での優先セッションのスケジュールを設定するためにパスワードが必要なのはなぜですか？
したがって、私がコードレビューのために連れて行かれ、あなたがこれを私に提起した場合、それは私たちが始めるところです。何を保護していますか？ 1人が他の1人としてログインすることによる悪影響は何ですか？誰もが保存しているデータが公開されることによる悪影響は何ですか多分彼らはひどいです。あなたは私のためにそれらをリストするでしょう。次に、「パスワードをメールで送信」をクリックできず、代わりに「パスワードをリセット」をクリックしなければならない場合、どのような影響がありますか？彼らはサイトの使用をやめるのだろうか？そして、その人としてログインしているスタッフはどうですか？それは時間、お金、売上の損失など何を節約していますか？
コスト/メリットの物語の最後の部分であり、現在さらされているネガティブと機能を削除したときに得られるネガティブとの間に大きな違いがある場合にのみ得られるものは、それを修正するためのコストです。 1000ドルの露出の機会を私に与えるために100万を費やすだろうか？いいえ。その逆はどうですか。オッズにもよりますが、私の最初の答えは「はい」でしょう。
ps-カナダ政府は、URLにIDが含まれているパスポートの申請サイトを公開しました。別のIDでURLを編集した場合、他のランダムな市民の半分完成したフォームが表示されました。そして、私は顧客サービスの目的で一般的な幸福のために顧客としてサインインするクライアントを持っているので、パスワードの背後にあるデータが見知らぬ人にとって実際に重要であるならそれを支持しませんが、それの良い面はわかります。
それは法律に違反する可能性があり、訴訟を起こす可能性があります。ユーザーに関するあらゆる種類の個人情報を保持している場合、またはシステムがユーザーとして他のシステムとやり取りしている場合は、システムが州または連邦のプライバシー法または法律に該当するかどうかを確認する必要があります。すなわち。 Sarbanes/Oxley、California OOPAなど.
潜在的な法的問題は別として、管理者はいつでもテーブル全体をポータブルデータスティックにダンプし、任意のユーザーとしてログインして大混乱を引き起こしたり、データを販売したりできる可能性があることも指摘できます。
すべての管理者が信頼できると仮定しても、管理者パスワードの侵害は壊滅的です。
また、ユーザーのパスワードを使用して操作を実行する必要もありません。 Sudoのような機能を実装できます。
FIPSであり、FISMAの要件により、パスワードの可逆暗号化が禁止され、親部門が月に叩きつけるため、これは連邦政府のシステムではない可能性があります。
そして、より強力なセキュリティポリシー（パスワードをハッシュして簡単に取得できないようにする）を実装するには、それらの既存の機能を削除する必要があります。
以前の会社では、この問題を回避するためにパスワード再設定メールを送信する機能を求めて戦い続けました。そして、私は却下され続けました。結局、潮にうんちをうんざりするのに飽きたので立ち去りました。これは先のとがった髪のボスでもあり、一部の銀行のWebサイトが尋ねる愚かな質問は「2要素認証」として数えられると考えていました。彼との議論はディルバートの漫画のようなものでした（彼はPHBのような形をしていました）。
さらに、実際にアプリケーション内に既存の機能があり、管理者ユーザーがユーザーのパスワードを取得して、それらのユーザーとしてログインし、必要なことを実行できます。
これは金融機関で実装されているのを見てきました。カスタマーサポートエリアのユーザーは、自分の資格情報を使用してログインし、権限がある場合は、顧客としてログインしているように見せかけることができます。これは顧客としてログインしませんでした顧客になりすました。そうすることで、カスタマーサービス担当者が出金を決定した場合、それを顧客がログに記録していることが示されません。カスタマーサービス担当者がそれを行おうとしていること（およびアラートが送信されてすぐに解雇されることを示す）が表示されます。レンタコップは彼らの床にそれを作ることができます）。
不十分に行われると、カスタマーサポートスタッフは、エンドユーザーが何らかの重大な経済的または法的責任を負う可能性のある活動に従事しているように見せることができます。
私が最後に取り組んだ連邦政府のWebサイトは、エンドユーザー（そのうち約400人のユーザー）から年間14億ドルを集めていたため、ログ記録は非常に厳しくする必要があり、許可されたエンドユーザーだけが触れることを許可されていました彼らが物品税を支払ったものを報告したウェブページ。
ソニーは最新のセキュリティ違反を抱えた企業の1つでした。それはPS3ネットワークだけではなく、MMORPGゲームのネットワークでもあり、合計で25,000,000を超える名前、住所、クレジットカード番号、ユーザー名、パスワードを超えています。あなたは信じることができます。私はまったく幸せではない（私は私のひび割れが欲しい！）。
私はこのような懸念について Software Engineering Code of Ethics を参照しています。私の解釈では、あなたの最優先事項は公共の利益を損なうことではありません（このようなパスワードが危険にさらされる可能性があるわけではありません ここの例 ここでは、会社がデルのラップトップを変更したため、レンタル会社は彼らなしで賃貸人をスパイできるようになりました）知っている）。その後、あなたの責任は潜在的なリスクをクライアントに知らせ、彼らにそれを考慮させることです。もちろん、それは最低限のベースラインです。あなたはこれがあなたがそれをあなたが待ち受けて許すことができるよりももっと多いと感じるかどうかのあなた自身の判断を使わなければなりません。
もちろん、政府のプロジェクトについて言及するとき、これらの慣行のために市民の個人情報が危険にさらされている場合、それは公共の利益を損なうことになります。
電子メールのリストと復号化されたパスワードを印刷して上司の机に置くことができ、表紙に「Confidential」という大きな警告が表示されます。
ただし、紙を無駄にしないようにフォントを小さくしてください。
また、管理者がパスワードを使用せずに管理者が他人になりすますことをBugzillaがどのように許可するかを示すこともできます。
これは政府のプロジェクトのためのものなので、心配です。ユーザーのパスワードを取得してIDでアクションを実行すると、あらゆる種類のセキュリティ監査から意味がなくなります。これについて私が見ることができる唯一の理由は、偽の監査証跡を作成することです。
パスワードに可逆暗号化を使用する必要は本当にありません。ユーザーIDを偽装する正当な理由がある場合は、次の方法で行うことができます。
- 現在のパスワードハッシュを保存する
- 既知の値で置き換える
- （偽の監査証跡活動、例：オフショアアカウントへの送金）
- 元のパスワードハッシュを置き換える
私は最後のステップに不快です-システムで偽装された人は誰でもそれが起こったことを知っているはずです。 「あなたが本当に必要であると言ったので、あなたの銀行があなたに知らないうちにあなたのアカウントにアクセスさせてくれたようです」と言ってビジネスを説得できるかもしれません。
まず、他の回答に同意します-これはmuchこれを回避する方が安全であり、パスワードのハッシュではなく、パスワード自体、またはパスワードに変換できるもののみを保存することを指摘します。
ただし、回復を可能にする必要がある場合があります。パスワードの場合、通常は、既存のパスワードを回復するのではなく、必要なときに必要に応じて管理者がパスワードを変更できるようにして回復します。
ただし、もう1つの可能性は、ユーザーが自分のパスワードで暗号化されたデータをサーバーに保存できるようにすることです。この場合、管理者にパスワードの変更を許可するだけでnotで十分です。新しいパスワードはデータを復号化するために機能せず、ほとんどのユーザーは、パスワードを忘れた/紛失した場合、暗号化されたすべてのデータにアクセスできなくなることは受け入れられないでしょう。この状況では、かなり安全な代替手段があり、本当に必要なときに回復を可能にします。
ユーザーのパスワードを使用してデータを暗号化する代わりに、ランダムキーを作成してデータ自体を暗号化します。次に、そのキーをいくつかの場所に保存します。一度ユーザーのパスワードで暗号化した後、別の場所に管理者パスワードで暗号化します。次に、ユーザーがパスワードを紛失してデータに直接アクセスできなくなった場合（実際にはそうではない）、管理者パスワードを使用して実際のキーを復号化し、それを使用してデータを回復したり、キーを再暗号化したりできます。ユーザーの新しいパスワード。
1人の管理者を完全に信頼したくない場合は、それも管理できます。たとえば、5人に管理者キーを割り当てることを決定でき、キーを回復する前に少なくとも3人が同意するようにすることができます。この場合、管理目的で暗号化されたパスワードを保存するときは、5人の管理者のうち3人のセットごとに1回ずつ、複数回保存します（複数を保存するだけなので、多くのスペースを必要としません- keys、それぞれ〜256ビットで、データの複数のコピーではありません）。これらの各コピーは、これら3人の管理者の各パスワード（のハッシュ）で連続的に暗号化されます。
暗号化を解除するには、パスワードを入力している3人の管理者を特定し、その3つのセットに適切な暗号化キーを選択してから、3つのパスワードのそれぞれを使用して復号化し、最終的に元のキーを取得します。次に、それを使用してデータ自体を回復するか、ユーザーの新しいパスワード（のハッシュ）でデータを再暗号化して、ユーザーが引き続きデータにアクセスできるようにします。
ただし、これを行う場合、本当には標準の暗号化アルゴリズムを使用する必要があり、（強い好みにより）標準でよく知られている、徹底的に研究された実装を使用する必要があります。
より良いパスワードシステムへの信念は問題ではありません。管理者/サポートがユーザーアカウントを偽装してパスワードの修正を提供できるようにするソリューションを作成します。セキュリティは、利便性のためにしばしば損なわれます。便利で安全です。
編集：パスワードのセキュリティ問題を完全に理解することは決してありませんが、機能が失われることは理解しています。この提案を行い、必要な変更を加えるための承認を得ることができるかどうかを確認してください。彼らはそれが1時間または1年かかるかどうかさえ知りません。これは機能の変更であり、完全な再構築ではありません。
これはお勧めしませんが、パスワードを解読する能力が絶対に必要な場合は、公開キー暗号化を使用する必要があります。これにより、公開鍵を使用してすべてのパスワードを暗号化できます。公開キーで暗号化して比較することでパスワードを確認でき、秘密キーを別の場所（運用コンピューターではない場所）に保持できます。
現在のイベント（EpsilonデータリークとPlayStation Networkデータリーク）を考慮すると、問題が明白であることを期待しています。
ただし、開発者がポリシーに影響を与えることができない場合もあります。
スキャンダルの可能性と経費の可能性を示すために最善を尽くします。これもまた、時事問題を考慮して簡単なはずです。しかし、それがうまくいかない場合、本当に何ができますか。あまりない。抗議して終了し、注意を喚起するために脆弱性を示します。どちらも素晴らしいオプションのようには聞こえません。
通常、管理者がユーザーパスワードを表示するのは、紛失した場合に備えて、ユーザーにパスワードを提供できるためです。私の知る限り、Windowsは管理者にもパスワードを表示させません。それでは、なぜアプリケーションが必要なのでしょうか。社内の暗号化ライブラリは、NSAでは機能しないと書いた人はだれでもいるため、必ず破られます。