認証システムが機能していること、および顧客が間違ったパスワードを使用していることをどのように証明しますか？
たまに（まれですが）、一部のユーザーは自分のパスワードが機能しないと言います。正しいパスワードを入力したのに'wrong password'メッセージが表示されたそうです。
パスワードのリセット機能を使用するように指示しますが、認証システムが機能しない場合がありますのように感じます。
私たちの推測では、彼らのパスワードは覚えているものではありませんが、プレーンテキストで保存しないので、そのことを証明する方法はありますか？
場合によっては、特定の日付にパスワードを変更してから忘れてしまったことを示すことができ、満足していた。しかし、常にそうであるとは限りません。
hashは元に戻せないように設計されているので、これを証明する迅速な方法はありません。
要求されたパスワードを取得し、手動でハッシュを生成する@ TechTreeDevの推奨事項 を使用できます。ソルトハッシュ（BCryptなど）を使用する必要があるため、必ず同じソルトを使用してください。
手動で生成されたハッシュが一致する場合、ログインコードに問題があることが判明しています。
生成されたハッシュが異なる可能性が高いため、ログインコードの問題が除外されていますが、に問題がある可能性がありますパスワードの設定、または手動生成の誤り。
これは、1人のユーザーのパスワードを確認するためにできることの範囲です。その上で、システムテストを行います。
断続的/ランダムチャンスのEdgeケースが疑われる場合は、monkeyテストスクリプトを作成してパスワードを設定し、それらを試すことができます。しかし、このアプローチはおそらくやり過ぎです。
最善の方法は、ログインコードと、パスワードをリセットするすべてのポイントを確認することです。コードはできるだけ短く、簡潔にする必要があります。私の経験では、Edgeケースの問題を除外する最善の方法は、コードレビューを使用することです。そのようなEdgeケースは、多くの場合、手動テストではカバーされません。
特に探すべきいくつかの事柄：
maxlengthの設定がどのパスワードでも一貫している（または、まだ存在していない）ことを確認してください<input>s。パスワードの設定とログインフォームの一貫性を探しています。サーバー側truncationがないことを確認してください。
encodingが一貫していることを確認してください。パスワードに非ASCII文字が使用されている場合、パスワード設定フォームとログインフォームはまったく同じように動作する必要があります。
また、whitespaceやnon-ASCIIなどの文字をパスワードから自動的に削除しないでください。これは、コードが簡潔な場合、コードレビューで簡単に把握できる種類のことです。
最後にいくつかの人間のヒント：
最初にcorrect usernameを使用していることを確認します。
caps lock設定が正しいことを確認します。
カスタマーサポート担当者に、ログインまたはパスワードリセットのすべての日付/時刻のログを提供します。最後のリセット以降に1回以上ログインがあった場合、システムを知っています。正しく機能しました。
ログインコードが変更されておらず、ハッシュが最後の成功以降変更されていない限り、問題のタイプミスがパスワードであることが合理的に確実である可能性があります。
間違ったパスワードエラーのUXを確認してください。ユーザーにいくつかの簡単なヒントと可能性の信頼できる説明を提供します。これにより、カスタマーサービスへのコールインを減らすことができます。
email notifyパスワードがリセットされたときに、通知するのに役立つ場合があります。 （または共有アカウントの場合は他の家族）
確実に知る方法が1つあります。それは、ユーザーが入力したもののハッシュを計算し、同じソルトを使用して、それを現在のものと比較することです。しかし、それはログインプロセスがすでに行っていることであり、ユーザーはそれを信じていません。あなたが彼らのためにそれをするとき、なぜ彼らはそれを信じなければならないのですか？
代わりに、たとえばWindows 10だけでなく、Webサイトでも、最近よく見ていることを実行できます。
ユーザーに入力内容を確認する方法を提供します。
もちろん、ログインするとき、文字はドットまたは他の文字として表される必要があります。そのため、スヌーパーはユーザーの肩越しにパスワードを見ることができません。
しかし、入力フィールドにある限り、まだ暗号化もハッシュも行われていません。これらのドットを実際の文字に変換するボタンを提供してください。
そのようにして、間違ったパスワードを入力した後、もう一度入力して、入力した内容を確認できます。または、ログインする前に確認することもできます。
忘れられたCapsLock、ぶら下げシフト、タイプミス。これらはすべて、この方法でユーザーが検出できます。
ユーザーエクスペリエンスを向上させるには、まず次の条件をユーザーに知らせるためのUIを追加する必要があります。
- Caps Lockが有効になっています
- ユーザー名に末尾の空白がある場合の警告
- パスワードの末尾に空白がある場合の警告
- メールで空白を使用しないようにします（ユーザー名の代わりにメールを使用する場合）
- 使用を防ぎ、自動的に改行を削除します（いくつかの改行バリアントがあります）
- 制御文字の使用を防ぎ、自動的に削除する
- javascriptを使用している場合、一部のブラウザーではJavascriptが無効になっているため、これらの手順をサーバー側に移動する必要があります。
また、挿入されたパスワードが間違っていると、次のメッセージが表示されます。
パスワードまたはユーザー名/メールが間違っていますタイプ小文字または大文字とすべての記号番号に注意して、一致する必要があります完全に。テキストをコピーすると、不要な空白や改行が追加されることがあるので、コピーと貼り付けは行わないでください。
ユーザーは正しいかもしれません！ Webページへのログインが許可されていない古い電話を持っていたことがあります。それがテキストエンコーディングの問題かどうかはわかりませんが、パスワードが英数字でPCで完全に機能しました。
受け入れられた答えは本当にそのほとんどをカバーしています。しかし、そこですべての提案を試しても問題が見つからなかったとすると、エラーが発生したときにエラーをキャッチしようとします。これを行うには、ユーザーが2回続けてログインに失敗した場合に、受信したプレーンテキストのパスワードをログに記録するコードを追加します（これにより、愚かなエラーを起こしたユーザーをすべて除外し、2回目の試行で修正しました）。
システムのセキュリティを低下させないために、実際に電話でログインに問題のあるユーザーがいるときにのみパスワードのログを有効にし、ユーザーの同意を得てそのユーザーのパスワードのみをログに記録することができます。
アプリケーションで表示される実際のパスワードをログに記録すると、アプリケーションで表示されるとおりに正確に表示できるという利点があります。絶望的なユーザーから何回か電話をかけた後、ログインコードの問題を指摘するパスワードのパターン（たとえば、末尾のスペース、特殊文字など）を拾い始めるか、またはmeantと入力して「mysweetheart」を入力し、代わりに「myseetheart」と入力した場合、ログインの問題がすべてのユーザーエラーである可能性が高いことを意味します。
この実際のプロパティを持つ4つの異なる認証システムに遭遇すると、それぞれのケースで確認するのはかなり簡単です。
ケース1：システムがランダムに失敗する。失敗した場合、不正なログインカウンタは増加しません。 （内部を確認することはできませんでしたが、別のサーバーとの接続が失われることがあり、これが発生すると誤ったパスワードを報告するだけであることがわかっています。）
ケース＃2：パスワードにアポストロフィを入力すると、システムが停止しました。パスワードフィールドがSQLインジェクションの影響を受けることを示すのは簡単でした。
ケース＃3：パスワード画面にないログイン画面の文字フィルターによって、有効なパスワードが拒否されました。これも問題を実証するのは簡単でした。
ケース＃4：アットマークをkill行と解釈したため、システムはログインできません。ブーー。 FTPポートにTelnetでログインして、正しいパスワードを持っていることを証明しました。
パスワードハッシュの手順を手動で実行することが解決策になるとは思いません。実際に失敗することを検出した場合、確かに、デバッグするために低レベルで実行できますが、顧客はほとんどすぐにそれを忘れてしまいます。
ここで問題は、パスワードを間違って入力したか、実際に使用したものとは異なるものを実際に使用したと考えられるために、間違ったパスワードを使用していることです。
最初のケースを除外するには、テキストエディタ（メモ帳など）で目的のパスワードを書き、クリップボードに切り取り、パスワードフィールドに貼り付けます。パスワードはプロセス中にお客様に示されるため、間違った文字が押された場合を排除し、Caps Lockが設定されました... ）
2番目のケースは、パスワードを含むテキストファイルを保持することを顧客に勧めたくないため、より困難です。理想的には、KeePassのようなパスワードマネージャーを使用するように顧客を説得します。次に、パスワード（以前に機能したものと同じ）がパスワードマネージャから正しくコピーされた場合、それが本当に正しいパスワードであると確信できます。
それ以外に、顧客の心の変化が本当に必要な場合は、顧客に次のことを依頼することができます。
- 新しいパスワードを作成する
- 貼り付けてパスワードを変更します
- クリップボードにある同じパスワードでログインしてみてください
それを再現しようとするために、彼らが好きなだけ何度でも。
ユーザーがログインするたびにログインしていると仮定すると、ユーザーが最後にパスワードを変更してからログインできたことを示すことができます。これは、潜在的な問題を除外するには十分です。
私は昨日考えた2番目の回答を投稿しますが、それが賢明かどうかはわかりませんでした。
暗号化された形式でパスワードセット/リセットおよび試行の一時的なログを作成できます。セキュリティの専門家（私を含む）は、パスワードを（ハッシュする代わりに）暗号化する（または、誤ったパスワードを入力する）ことについてこの考えに身震いするので、この情報の記録を開始する必要がある場合は、3つの予防策を提案します。
- 情報を別の/隔離されたコンピューターに送信してください。メインサーバーが危険にさらされている場合でも、パスワードログは安全です。
- ログに記録された情報には公開鍵（非対称）暗号化を使用します。秘密（復号化）キーは、開発者がログに記録されたデータを確認できる分離された環境にのみ保存されます。
- 特定の日付、または十分な数のテストが成功したときに、この一時ログが無効になるようにタスクをスケジュール（またはコード化）します。
各ユーザーの最後のいくつかの（ハッシュされた）パスワードをデータベースに保存できます。入力したパスワードが現在のパスワードと一致しない場合は、古いパスワードと比較してください。一致する場合は、「古いパスワードを入力しました-再試行してください」というメッセージまたはエラーコードを提示します（そのため、彼らがあなたに連絡したときに、「エラーコード47が表示されますか？古いパスワードを使用しました。」）
このようにして、ログインシステムが少なくともいくつかのパスワードルックアップを行い、ユーザーが新しいパスワードを忘れたというフィードバックを受け取ることで、ログインシステムが機能していることをかなり確信できます。