ログイン成功後にユーザーが誤って入力したパスワードを表示しない理由はありますか？
問題のユーザー名が複数回のログイン試行に失敗した場合、ログインが成功したら、誤って入力されたパスワードを表示する必要があるという要件をクライアントが求めました。以前のパスワードを含む、正しく入力された情報表示されませんいずれの場合も。
私たちのリード開発者は、不正なエントリをハッシュしないことで技術的には可能であると私たちに伝えましたが、彼女は極端に機能に不快で、保留にされましたブレーンストーミング中です。
問題のウェブサイトは、あらゆる金銭取引をまったく備えていない広範なマッピング/ GISアプリケーションです。その他のログイン/認証オプションには、Google/LinkedIn/Twitter/facebookが含まれるため、そこにパスワードを保存する必要はなく、処理は主にUXの問題です。
このような機能の実装に伴うセキュリティの脆弱性は何ですか？私たちのクライアントは完全に技術的な知識がないわけではないので、一般的な説明で十分です。
質問が広すぎるか、答えが非常に明白である場合は、お詫びします。
主な問題は、誤ったパスワードを後でユーザーに表示できるように保存する必要があることです。これは、開発者が指摘したように、最初に暗号でハッシュすることができないことを意味します。その結果、それらをプレーンテキスト（不良）または暗号化（より良いが、通常は推奨されません）として保存します。
最大のリスクは、この無効なパスワードのデータベースが攻撃者にアクセス可能になるかどうかです。サーバーを危険にさらしたり、SQLインジェクションを実行したり、他の方法で取得したりします。強力にハッシュされてターゲットが強化されているプライマリパスワードを解読するのではなく、無効なパスワード履歴の情報を使用してアカウントを侵害する可能性があります。平文パスワードに簡単にアクセスするか、平文パスワードに復号化できる暗号化キーを見つけようとします。
ログイン失敗の一般的な原因は、パスワード入力プロセス中のマイナーなタイプミスです。したがって、私のパスワードはMuffins16ですが、Caps Lockがオンになっているため、mUFFINS16と入力します。または、同じキーを2回押すため、Muffins166。またはMuffina16です。私の指が間違ったキーを押したからです。ご覧のように、これらのバリエーションはオリジナルに十分に近いため、攻撃者はいくつかの小さな変更を試みるか、間違ったパスワードを辞書の単語または名前と比較することにより、無効なパスワードから有効なパスワードを判別できます。
ほとんどの人がランダムな文字列ではなく、パスワードの選択肢 これらの形式と同様 を使用するため、この問題は悪化します。無効なパスワードがV8Az $ p4/fAである場合、攻撃者がタイプミスを特定することは困難ですが、そのバリエーションを試し、情報なしで推測することははるかに簡単です。
もう1つのリスクは、ユーザーがこのサイトで使用したパスワードを覚えておらず、一般的なパスワードを試す可能性があることです。攻撃者がユーザーのアカウントを侵害するだけでなく、「無効な」パスワードの便利なリストを使用して他のサイトを侵害する可能性があるため、このサイトは突然より大きな標的になりました。
有効なログインに続いて表示された直後に無効なパスワードのストレージを消去することにより、これらのリスクの一部を軽減できます。これにより、攻撃者がデータにアクセスしてデータから利益を得る機会のウィンドウが制限されます。
あなたがおそらくあなたのクライアントに尋ねるべき質問は、彼らがユーザーが彼らの無効なパスワードを見ることから利益を得ることをどのように予測するかです。ユーザーがパスワードを誤って入力した方法を識別できるようにするためですか？入力ミスは意図的なものではないため、間違いを示すことで今後のログイン試行が改善される可能性は低いです。ユーザーはパスワードを推測しようとする攻撃者を特定できますか？試行されたパスワードなしで無効な試行が行われた日付、時刻、IP /ジオロケーション、またはその他の情報をリストすることによって、同様のフィードバックを提供できます。ユーザーはパスワードの入力中に失敗したことを知っており、サイトのログインシステムのせいにしないでください。これはメリットのある唯一のもののようであり、リスクを正当化するのに十分な価値を提供するかどうかはわかりません。
私の推測では、彼らがこの機能で何を達成しようとしているのかをよく理解したら、おそらくより安全な代替案を提案できるでしょう。
tldr;これは、パスワードをハッシュ化せずにプレーンテキストとして保存するよりもさらに悪いです。
私はあなたのリード開発者の懸念に同意します。過去の不正なパスワードの試行を表示するには、それらをリバーシブルな方法で保存する必要があります。つまり、ハッシュ化できません。誰かがシステムを危険にさらした場合、そのユーザーはすべての悪意のある試みにアクセスでき、一部のユーザーにとって本当のパスワードが何であるかをつなぎ合わせる可能性があります。たとえば、あなたが私の悪い試みのいくつかを見ることができる場合：
correct horrse battery staple
correct horse batttery staple
私の実際のパスワードは簡単にわかります。
私も drewbenn's answer に同意します。ユーザー名を間違って入力したが、正しいパスワードを使用していて、誤ったユーザー名が他人のユーザー名である場合、そのユーザーは私の実際のパスワードを見ることができます。
一度、パスワードを使用してシステムにログインしようとしましたが、同僚のユーザー名を使用しました。
そうすると、共有アカウントにログインしようとするときに間違ったパスワードを使用することがよくあります。
そして、私は多くの管理者が上司のアカウントへのアクセスを許可されているので、彼らは物事を成し遂げることができます。上司が間違ったパスワードを入力したことがなく、訪問者が注意をそらしてから正しくログインして間違いを解消したとしたら、私はかなりショックを受けます。
さらに、ログイン中に誰かが私の肩越しに立っているときのすべてのタイプミス。
これらすべてのケースで、Gmailまたはラストパスのパスワードを職場のパスワードプロンプトに入力したり、その逆を行ったりすることがあります。
また、画面を見ていなかったためにパスワードがグーグルでロックされたと思ったとき。それはあなたの提案とは関係ありませんが、everyoneは間違いを犯して間違ってタイプする可能性があることを人々に思い出させるので、その逸話を共有するのが好きです時々。
このhUnt3r2featureが行う唯一のことは、小さな間違い（間違ったパスワードの入力や入力ミス）を、より広い聴衆に誤って公開することです。
評判の喪失
このようなメカニズムを導入すると、ログイン試行の失敗が他のサイトへの攻撃に使用された注目度の高いケースがあったことを考えると、評判がすぐに失われます。次に例を示します。
マーク（ザッカーバーグ）は自分のサイトTheFacebook.comを使用して、クリムゾンのメンバーであると名乗ったサイトのメンバーを調べました。次に、失敗したログインのログを調べて、クリムゾンメンバーのいずれかがTheFacebook.comに誤ったパスワードを入力したことがないかどうかを確認しました。ログインしたケースがログインに失敗した場合、マークはそれらを使用してクリムゾンメンバーのハーバードメールアカウントにアクセスしようとしました。彼はそのうちの2つに無事アクセスしました。
言い換えれば、マークはTheFacebookからのプライベートログインデータを使用して、一部のTheFacebookユーザーの個別のメールアカウントにハッキングしたようです。
出典：マークザッカーバーグがハーバードクリムゾンに侵入した方法
代替
クライアントが次のサインオン成功時に失敗したログイン試行を表示することに熱心である場合、一種の気分が良い方法として、代替案を提案できますか？失敗したパスワードを表示する代わりに、不正なパスワードを送信したブラウザのIPアドレスと位置情報を表示します。かなり簡単に実行でき、セキュリティの問題を引き起こさず、実際の悪意のあるアクティビティの場合にはるかに役立つ情報を提供します。
これを行わないセキュリティ以外の理由：不正なログインスパム。
私はあなたのアプリケーションに対してメール/ユーザー名の私のリストを実行します。同じ「パスワード」で各アカウントにログインしようとしました。多分不快な言葉;政治スローガン、または単にいくつかのウェブサイトの広告。
次に、各ユーザーがログインします。ユーザー名/メールを推測したユーザーは、入力したものをすべて表示する必要があります。
これは、すべての匿名ユーザーに、コンテンツをユーザーに表示するためのベクトルを提供します。
それぞれがサービスを使用していて、お互いのログイン名を推測できる同僚の場合、これは嫌がらせやその他の職場の人事問題につながる可能性さえあります。
アプリにログインしたいのですが、同僚と一緒に座っているとどうなりますか？パスワードを間違って入力したとします。ログイン中にパスワードを送らないようにして、パスワードが表示されないようにする必要がありますか？
ユーザー名/メールアドレスが類似しているユーザーがいる場合、誤って別のユーザーのアカウントにログインしようとする可能性があります。
悪意のあるユーザーは、「不正な」パスワード試行のリストを使用して、類似のユーザー名/メールアドレス（bill11、bill1など）を持つアカウントに侵入する可能性があります。
時間と関連するIPアドレスとともに、失敗したログイン試行と成功したログイン試行を単純にリストするほうがよいと思います。
攻撃者が失敗した試行のリストを入手した場合、ユーザーのパスワードを簡単に推測できると指摘する他の回答にも同意します。
その場合、システムに金銭取引情報が含まれていないことは問題ではありません。複数のサイトでユーザーが同じパスワードを使用したり、同じパスワードのバリエーションを使用したりすることはよくあります。彼らはそれをしないように助言されるかもしれませんが、それでも起こります。したがって、システムが機密情報自体を公開していると感じなくても、システムが危険にさらされてもユーザーの機密情報が危険にさらされることはありません。
Joe Userが自分の銀行で使用しているのと同じパスワードをシステムで使用している場合、攻撃者がシステムで自分のパスワードを推測し、Joeが使用している銀行を突き止めることができれば、攻撃者はJoeの銀行口座にアクセスできる可能性があります。または、医療記録、またはジョーがそのパスワードを使用した他のシステム。
システムのパスワードを保護するだけではありません。
あなたのクライアントは XY問題 に苦しんでいると思います。これは、一歩下がって、クライアントが本当に望んでいるものを理解しようとすることを意味します。多くの場合、その誰かが間違ったパスワードを試したことと、どうやってこれを知っていると便利ですパスワードが入力されましたが、必ずしもwhatでした。おそらく、クライアントは、自分のパスワードの太い手指などの無害な脅威と、以前にログインしたことのないデバイスで国の途中からパスワードを推測するなどのより疑わしい脅威とを区別するのに十分な情報を必要としているだけかもしれません。
したがって、クライアントに脅威モデルについて尋ね、次の情報で十分かどうかを確認してください。
- 認証が失敗したユーザーID（失敗ごとに誰に警告するかを知ることができるようにするため）
- 日時
- クライアントIPアドレス、ユーザーエージェント、おおよその位置情報
- クライアントがJavaScriptを実行するかどうか（攻撃者はたいてい気にしない）
- クライアントが過去に正常にログインしたことに対してCookieを提示したかどうか
次に、1つ以上の失敗後にユーザーが正常にログインしたときに、この情報に基づいて警告ボックスを表示します。
ここですでに優れた答えを追加するのをためらいますが、別の重要な点があります。ユーザーがHTTPSを介してのみサイトに接続することを確実に確信している場合を除いて（そして、実際には、それでもそうではありません）、不正なパスワードを表示する機会さえもないはずです...最初の場所。クライアントシステムは、実際のパスワードではなく、ソルトハッシュのようなものだけを送信する必要があります（適切な実装では、ハッシュ自体がパスワードにならないようにします（つまり、盗まれて再利用される可能性があるもの））。これにより、盗聴攻撃を防ぎます。
そして、サイトが金融取引を処理していないことは問題ではありません。あなたはまだそれがいくつかのチェーンで最も弱いリンクになることを望まない。
このため、私は完全にあなたのリード開発者と一緒です。私はこの「機能」に対して歯と爪を戦っています。
考えられる解決策：ここでの問題は、不正なパスワードの試行をプレーンテキストで保存することに関するものであるため、避けてください。ユーザーのパスワードを設定したら、公開鍵と秘密鍵のペアを生成します。パスワードで暗号化された公開鍵と秘密鍵を保管します。正しくないパスワードをログに記録する場合は、公開鍵で暗号化します（そしてソルトを追加します）。このようにして、正しいパスワードを知っているユーザーだけが誤ったパスワードを見ることができます。
システムには、パスワードの復号可能な大規模なデータベースがあります。ユーザーXの誤ったパスワードを調べると、Xのアカウントのほとんどではなく完全に正しいパスワード、ユーザーXのさまざまなアカウントの正しいパスワード、さらにXとほぼ同じユーザー名を持つユーザーのアカウントの正しいパスワードが得られます。
ハッカーがシステムに侵入し、データベースの復号化されたコピーを入手する可能性があるという合理的な想定があれば、これは悲惨なことです。間違った人によるシステムへのアクセスがそれほど重要ではないと仮定しても、そのデータベースには、さまざまなシステムのユーザーのパスワードが含まれます。
適切に構築された認証では、ユーザーが入力したパスワードはホストサイトにも送信されないように思われるため、不正な試行を保存する問題は疑わしいものです。
インターフェースに「パスワードを表示する」チェックボックスがあってもかまいません。これは厳密にローカル機能であり、パスワードの入力時または試行の失敗後に使用できます。おそらく、保存された情報は、放棄されたコンソールからのパスワードの収集を防ぐために、しばらくしてから消去する必要があります。