パスワード回復/回復質問のプロセスフロー
ユーザーが「パスワードを忘れた」からパスワードを回復できるアプリケーションを作成しています。リンク。ユーザーがリンクをクリックすると、アカウント登録プロセス中に記入したであろう回復の質問が表示されます。質問に正しく記入すると、ログイン時に更新する新しい一時パスワードが記載された電子メールを受け取ります。
私の問題は、回復の質問画面にあります。ユーザーが回復の質問を思い出せない場合、ユーザーが最初にパスワードを取得せずに質問をリセットできるようにするためのベストプラクティスはありますか？
ユーザーが復旧質問のリセットを要求するカスタマーサポートの問題になる可能性があると考えていますが、ユーザーとサポートチームの両方にとって非効率的で不便であることがわかりました。誰かがこの問題を解決し、ユーザーが回復の質問をリセットできるようにするプロセスはありますか？.
私はこの問題について（スペイン語で）いくつかの記事を書きました。明確な答えは次のとおりです：多要素認証を使用。私はそのアプローチを本当に嫌いです。これらの記事では、実際のユーザー事例を使用して、必ずしも安全であるとは限らないことを示しましたが、それらは常に恐ろしいユーザーエクスペリエンスにつながります。
詳細に触れずに、次のように簡単に説明します。デバイスでアクションを実行したいが、別のデバイスで追加のアクションを実行するように求められた場合は、ほとんどのUXヒューリスティックを再構築します。それと同じくらい簡単です。多分それはより安全ですが、使いやすさは悪夢になります（単純なケース：手元に別のデバイスがない場合はどうなりますか？）
他のアプローチ
最も安全で最も安全で最も使用可能な方法は、ユーザーが実際に覚えることができるキーと回復の質問を使用できるようにすることです。ユーザーが必要な場合アクセス情報を書き留めておくと、セキュリティが大幅に低下します。しかし、ほとんどのシステムのセキュリティに関する質問は非常にクレイジーになり、ほとんどのユーザーはそれらを書き留める必要があります！
下の画像を確認してください：
馬鹿げて覚えやすいパスを破ることはほとんど不可能です。 おそらく良いものは3日かかります。ユーザーが覚えているとしましょう！
使いやすさとCX角度
あなたが正しく言ったように、これはCXにとって本当に負担になるかもしれません。存在すべきではなかった問題に対して、より多くの労力とより多くの人々を適用する必要があります！しかし、これが唯一の問題ではありません。ユーザーとして、アカウントにログインするたびにカスタマーサポートに連絡するか、新しいパスワードを要求する必要がある場合、それはサービスの使用を停止するまでの時間の問題です
ユーザーを愚かに感じさせない：ユーザーエクスペリエンスのレッスン
ポイント：顧客が製品やWebサイトに不満を持っている場合、それらは失われます。このアプローチでは、彼らを愚かに感じさせるだけなので、彼らを取り戻すことはできません。顧客は製品を購入したいと思っています。長いサポートが必要な長く引き延ばされた体験に変わったら、それは彼らが決して満足することのない製品です。
じゃあ何をすればいいの？
これはあなたとあなたの設定に完全に依存しますが、私は以下のヒントをお勧めします：
- アクションは同じデバイスで実行する必要があります。常に。例外なし。
- 最も単純なアクション（を実行するためにユーザーがあなたを呼び出す必要がある場合：例：サイトに入る、doh！）...あなたは彼女を失うための道を進んでいます
- パスワードの再利用を許可します。ユーザーがそもそもそれらを選択したのには理由があります。
- リカバリー質問を使用する場合は、それらを本当に覚えやすくします。私は本当に私の最初の学校名、または私の最初のペットの名前（犬、猫でしたか？）を覚えるように努力する必要があります。代わりに、独自の回答を作成するようユーザーに提案します： "回答があなただけに知られているセキュリティの質問を作成してください"
- 自動化を使用します。デバイスとその場所を簡単に特定できる場合は、「メールで新しいパスワードを要求する」で十分です。
- ユーザーはセキュリティについて不満を言うことはありません。不平を言うのは主に都市の伝説に基づいた利害関係者だけです
- 長所と短所を比較検討します。ユーザーのアカウントが影響を受けていると仮定して...何が起こる可能性がありますか？機密データはありますか？それとも単なる「Facebookのような」ものですか？
- 上記を実行したら、システムのユーザビリティがどのように影響を受けるかを検討します
- 常に覚えておいてください：セキュリティはユーザーの責任ではなく責任です！
秘密の質問の問題
セキュリティの質問は、追加のセキュリティ層を提供するためにアプリケーションに実装したいもののように思えるかもしれませんが、ユーザーのアカウントのセキュリティに価値のあるものを実際に追加しているわけではありません。 Googleによる調査 は、非常に大規模なユーザーベース全体で、セキュリティの質問は、次のいずれかの理由で、追加のセキュリティ層を提供するのにほとんど効果がないことを示しています。
- 忘れた
質問の記憶力は時間の経過とともに大幅に減少します。たとえば、「Favorite Food？」という質問の成功率は、 1か月後には74％、3か月後には53％、1年後にはわずか47％です（セクション4.2）。
- 回答は公開されました
公開されている回答。 Rabkinは、質問の16％がオンラインソーシャルネットワーキングプロファイルに日常的に公開されている回答を持っていることを発見しました[27]。ユーザーがソーシャルネットワーク上でデータを非公開にしても、推論攻撃はユーザーの友人からの機密情報に近似することを可能にします[24]。その他の質問は、公開されている記録で確認できます。たとえば、テキサス州の住民の母親の旧姓の少なくとも30％は、出生と結婚の記録から推定できます[15]。
- 回答は統計的に十分一般的であり、すぐに推測することができました
秘密の質問に対する統計的攻撃は、多くのユーザー間で共有される共通の回答があるため、本当のリスクです。たとえば、単一の推測を使用すると、英語を話すユーザーの回答を「お気に入りの食べ物ですか？」と推測すると、攻撃者は19.7％の成功率になります。 ... 10回の推測で、攻撃者は韓国語を話すユーザーの回答の39％を「誕生の都」と推測することができます。 （セクション3.1）。
さらに、データ侵害が発生し、質問への回答が漏洩した場合、悪い報道が山積していることになります（下の wired.com 記事からの引用）：
「申し訳ありませんが、Yahooアカウントをお持ちの場合は、新しい母親を見つける必要があり、別の道で育ちました」ペンシルバニア大学のコンピューターサイエンティストのMatt Blaze Twitterに提供 Yahooのデータの後に違反の発表。
より優れたUXソリューション
ユーザーが登録済みの電子メールアドレスにアクセスして（一時的な平文のパスワードを送信することによって）パスワードをリセットする必要があるという前提にすでに依存しているため、セキュリティの質問をすべてまとめて、トークンベースのリセットに移行することをお勧めします。処理する。ユーザーにとって、パスワードリセットプロセスは次のようになります。
- ユーザーがパスワードを忘れ、パスワードを忘れたフォームでメールを送信する
- ユーザーはパスワードリセットリンクが記載されたメールを受け取ります
- ユーザーがパスワードリセットリンクをクリックすると、パスワードリセットフォームが表示されます
- ユーザーはフォームに新しいパスワードを入力して送信します
- ユーザーは新しいパスワードでアプリケーションにログインします
バックエンドで、アプリケーションは次のことを行う必要があります。
- ユーザーが「パスワードを忘れた」リクエストを送信すると、次のようになります。
a。アプリケーションはランダムなトークンと有効期限のタイムスタンプを生成し、データベースに保存します
b。アプリケーションは、URLパラメーターとしてリセットリンクにランダムトークンとアカウント識別子（メールやIDなど）を含むメールをユーザーに送信します - アカウント識別子とリセットトークンは、リセットフォームの非表示フォームフィールドに配置されます
- ユーザーがリセットフォームを送信します。アプリケーションは、リセットトークンが、データベースに保存されている特定のアカウント識別子と一致することを確認します。アプリケーションは、現在の時刻がリセットトークンの有効期限のタイムスタンプ以降でないことを確認します。アプリケーションは送信されたパスワードをハッシュし、データベースに保存します。 （オプションですが、良い習慣です）アプリケーションは、パスワードのリセットを送信したリクエストのタイムスタンプとその他の識別情報を保存します
ユーザーの観点から見ると、これははるかに使いやすいシステムです。ユーザーは登録したメールアドレスを知っているだけでよく、リセットプロセスの技術的なセキュリティ（時間制限があり、長くランダムに生成されるリセットトークン）は、操作する必要がないものに抽象化されます。個人を特定できないデータ（来年施行されるGDPRへの懸念）を保存するので、ユーザーは顧客サービスに連絡して別の方法で身元を確認する必要はありません。
アカウントのセキュリティと追加の確認が大きな懸念事項である場合は、時間をかけて2番目の帯域外確認を実装する必要があります。たとえば、SMS 2番目のトークン。
追加の読み：
秘密、嘘、アカウント回復：Googleでの個人的な知識の質問の使用からの教訓 -Google
セキュリティの質問を殺すまでの時間—または嘘で答える -有線
パスワード復旧の質問が役に立たないよりも悪い7つの理由 -Dashlane
送信[〜＃〜] otp [〜＃〜]登録済みの携帯電話番号、または回復用メールIDサインアッププロセス時に使用された番号。上記のオプションのいずれかを選択するようにユーザーに要求できます。
Devinポイントに同意します
リカバリー質問を使用する場合は、覚えやすくします。私は本当に私の最初の学校名、または私の最初のペットの名前（犬、猫でしたか？）を覚えるように努力する必要があります。代わりに、ユーザーに独自の回答を作成するように依頼します。「自分だけが回答を知っているセキュリティの質問を作成してください」