ユーザーにTOTPシークレットを自動的に生成する代わりに選択させるのは悪い考えですか？
スマートフォンを1回限りのコードジェネレーターとして使用するTOTPベースの認証システムについて読むと、通常、共有シークレットは「サーバー」（ユーザーが認証する必要があるシステム）によって自動的に生成され、Base32または「人間が読める」文字のみを生成するその他のエンコーディング。その後、ユーザーは自分のスマートフォンアプリにその秘密を入力し、ワンタイムコードの生成に使用されます。多くの場合、サーバーが生成したシークレットはQRコードにエンコードされて電話でスキャンされ、ユーザーがアプリに簡単にシークレットを入力できるようになります。
上記が典型的な構成であると確信している（私にはわかりません）と仮定すると、ユーザーに共有シークレットを選択させて、サーバーに送信する代わりに、共有シークレットを通信させるデメリットは何なのでしょうか。逆に。
つまり、ユーザーは共有シークレットを作成し、それを自分のスマートフォンアプリとサーバーの両方に保存し、サーバーはそのようなシークレットをそのまま使用します（つまり、エンコードされているとは見なさない）。または、ユーザーがシークレットを作成し、それをサーバーに保存する前にBase32にエンコードすると、サーバーはそれをエンコード済みと見なします。
私の理解では、これらの2つのケースのいずれも典型的なTOTPシステムが機能する方法ではないため、ユーザーに共有シークレットを選択させない理由があると私は確信しています。
[〜＃〜] added [〜＃〜]：ここにはかなりの情報があり、多くの疑問が明らかになりました。しかし、私はまだ疑問があります。私が理解したように、2要素認証のポイントの大部分は、あなたが何かknow（通常のパスワード）とあなたが何かhave（コード生成デバイス）を組み合わせることです、しかし、デバイスは一般的なスマートフォンにすることができ、ユーザーが秘密を入力することによってのみコード生成デバイスになります（QRコードやキーボードなどは関係ありません。それでもユーザーが必要とする情報の一部です） to knowそしてそれはそれが取るすべてです。 「シークレットはあなたが何か知っているまたは持っているパスワードと同じぐらいの何かだ」と主張している人に何を返信すればいいのかわかりません。
言い換えると、銀行がユーザーにログインするために提供するコード生成デバイスが、ユーザーhasではなく、ユーザーknowsではないことを理解しています。ユーザーに渡される前にそのデバイスにシークレットが設定されているため、ユーザーはシークレットを知らないため、ユーザーが認証に成功した場合は、実際にデバイスを持っているのが本人であることを意味します。ただし、デバイスが一般的なスマートフォンであり、ユーザー自身が秘密を入力することになっている場合（たとえば、QRコードを介して）、認証が成功するのは、秘密を知っていて、その秘密を入力した人物であることだけです。彼女のスマートフォン。
より良い質問は次のとおりです：なぜあなたはそれをするのですか？
認証プロトコルを開発するときは、すべての変数を制御します。つまり、たとえば、使用するRNGが安全であること、既存のシークレットを再利用していないこと、および「弱い」鍵を選択していないことを確認できます。さらに、ユーザーから秘密を取得するために安全なサイドチャネルに依存するという問題はありません。
ユーザーにシークレットの生成を許可すると、すべてが破棄されます。
ユーザーに自分の秘密を選択させる唯一の歴史的な利点は、ユーザーがそれらを自分のメモリにコミットでき、（潜在的に安全でない）ローカルストレージに依存しないことです。 TOTPの場合、その利点すらありません。ユーザーは、現在のコードを取得するために何らかの形のソフトウェアに依存する必要があります（2FAのポイントは、ユーザーに「持っているもの」へのアクセスを強制することです） 「彼らが知っているもの」に加えて）。
だから、はい、それはあまり良い考えではありません。
あなたはそれをすべきではありません。 [〜＃〜] totp [〜＃〜] はキーと同じくらい安全であり、ユーザーはランダム性の優れたソースではありません。
これに加えて、ほとんどのユーザーはスマートフォンをTOTPジェネレーターとして使用し、スマートフォンのキーボードで長く十分なランダム文字列を入力するようユーザーに要求すると、要求が多すぎます。ここで2を掛けます。ユーザーはスマートフォンとシステムで、大文字と小文字が混在する長いTOTPキーを入力する必要があります。
うまくいきません。ユーザーに写真を撮らせることをお勧めします。