web-dev-qa-db-ja.com

セキュリティの質問なしに暗号化されたデータで「パスワードを忘れた」機能を処理する

暗号化されたユーザーデータを処理するときのパスワードリセット機能の処理に関する この質問 のフォローアップの一種として、暗号化されたWebアプリケーションでユーザーのパスワードをリセットするための適切な方法がありますなし秘密の質問を使用していますか?

セキュリティの観点から言うと、問題は、最初の(パスワード)が失われた場合にデータをロック解除するために2番目のキーが必要になることになります。

  1. セキュリティの質問

    • セキュリティとユーザーエクスペリエンスの両方の懸念事項があるため、これらを実装したくありません(私の経験では、質問が曖昧になり、ユーザーがそれらを覚えていない可能性が高くなります。または、回答が公開情報となり、全体が無効になります目的)

    • これは確かにほとんどのユーザーが慣れ親しんでいるアプローチであり、他に良い解決策が見つからない場合に実装するアプローチです。

  2. バックアップキー

    • Appleの「回復キー」の例は、Apple IDに対して2要素認証を有効にすると印刷されるはずです

    • これは、ユーザーが回復キーを使用しない、または使用して後で回復キーを失う追加の手順であり、混乱とユーザーエクスペリエンスの低下につながります。

    • 他の可能性としては、必要になるまで2番目のキーを保存するユーザーのモバイルデバイス上のアプリがありますが、それは私にはやり過ぎのようで、おそらくユーザーが忘れるステップであり、ユーザーが取得したときにアプリが再インストールされない原因になりますたとえば新しい電話

  3. 何らかの形のキーエスクロー

    • ここで私が最初に考えたのは、ユーザーが外部アカウントをOpenID Connectに接続できるようにすることでしたが、一般的なプロバイダー(GoogleやFacebookなど)は、2番目のキーとして役立つ種類の一意で安定した秘密の値を返しませんアカウントに(Googleから最も近いものは一意のアカウント識別子であり、Googleアカウントへのアクセスを要求するすべてのサイトが受け取ります)

私がここで見落としたオプションや、セキュリティの質問を含まない、だれもが考えることができる賢い解決策はありますか?

編集:明確にするために、この特定のアプリケーションでは、私(またはシステムの他の開発者や管理者)は、いつでも暗号化されていないデータにアクセスできないことが要件です。つまり、ある時点で、データを復号化するためのキーにアクセスできる必要があるため、ワンタイムコードを送信するなどの方法では不十分です。 (この制限では、ユーザーがデータを解読するためにキーを送信するときに、キーがメモリ内に存在する短い時間は除外されます。アプリケーション自体が漏洩/保存されるのではなく、データのダンプをオフラインで解読することの方が心配ですキー)

13
MPLewis

秘密の質問の問題についてあなたに同意します。

ユーザーに携帯電話番号をバックアップとして提供して、ワンタイムコードをテキスト送信できるようにして、ユーザーが本人であることを証明するために入力するのはどうですか。 Yahooが実際にこれを行っているのは、実際のところです。そこで無料のアカウントを作成して(またはおそらくすでに持っている)、この機能をテストすることができます。

唯一の問題は、ユーザーが携帯電話を持っている必要があることです。ただし、Key Escrowソリューションですでに携帯電話について言及しているので、ユーザーが携帯電話を持っていることが予想されると思います。

1
V_RocKs