TOTPシークレットを平文または暗号化されたデータベースに保存しますか？
私は2FAとその使用方法について読んでいますが、最も印象的だったのは、誰もがTOTPシークレットをプレーンテキストとしてデータベースに格納しているように見えることです。
OTPを検証するために秘密をプレーンテキストとして必要とするので、ハッシュすることはできませんが、データベースが漏洩した場合に備えて、少なくともある方法で暗号化できませんでしたか？これをもう少し安全にする方法があるように感じますが、私が持っているアイデアに落とし穴があるかどうか疑問に思っています。
- サーバーに保存されているキーを使用してTOTPシークレットを暗号化する：同じキーですべてを暗号化するため、これは理想的ではありませんが、攻撃者がすべてに完全にアクセスできなくてもデータベースが漏洩する可能性がありますサーバー上のファイル。そのシナリオでは、少なくともTOTPシークレットは引き続き保護されます。
- ユーザーパスワードを使用してTOTPシークレットを暗号化する：ユーザーがログインし、パスワードハッシュチェックが有効な場合、送信された同じパスワードをキーとして使用してTOTPシークレットを暗号化/復号化できます。ユーザーが最初に2FAを設定するとき、TOTPシークレットを暗号化するために使用できるように、パスワードを入力する必要があります。ユーザーが正しいパスワードでログインする場合、パスワードを使用してTOTPシークレットを復号化し、OTPを検証します。データベースが漏洩した場合、パスワードはハッシュ化され、TOTPシークレットが暗号化されるため、攻撃者はパスワードを知らない限り、アカウントに関する情報を入手できません。
- 両方の方法を組み合わせる：パスワードをローカルに保存されたキーと組み合わせ、これをTOTPシークレットの暗号化キーとして使用します。このように、データベースが漏洩し、攻撃者がパスワードを知っている場合でも、格納されているキーにアクセスできない限り、TOTPシークレットを解読することはできません。
これに欠陥はありますか？ある場合、それらは何ですか？ TOTPをプレーンテキストとして保存するよりも、何でもいいと思います。
2FAについてどこで読んでいますか。なぜ、誰もが秘密鍵をプレーンテキストで保存していると思いますか
TOTPについて話しているときは、おそらくRFC4226とRFC6238を読む必要があります。
はい、例えばGoogle PAMモジュールは、シークレットをプレーンテキストでユーザーのホームディレクトリに保存します。しかし、ご注意ください：HOTPアルゴリズムは2005年に公開され、iPhone 1は2007年に公開されました。HOTPアルゴリズムは、スマートフォン-どちらも後で公開されたTOTPアルゴリズムも。
ローカルマシンでの認証にHOTP/TOTPを使用している場合は、暗号化またはプレーンテキストの問題が内在します。ただし、OTPアルゴリズムは、信頼できるバックエンドシステムで使用するように設計されています。もちろん攻撃者がこのマシンの前に座る可能性があるため、ローカルマシンは信頼できません。
セクションを見てください 7.5共有秘密の管理、RFC4226 ：
ここでは、＃1で提案したように、共有シークレットを暗号化することをお勧めします。そしてもちろん、誰かが暗号化キーを取得した場合、認証は役に立ちません。しかし、これはバックエンドシステムであり、保護する必要があります。例えば。私たちの（免責事項！）オープンソースソフトウェア privacyIDEA は実際に共有秘密を暗号化し、ハードウェアセキュリティモジュールを使用する場合でも暗号化します。 （繰り返しますが、これはバックエンドシステムです）
Google Authenticatorの設計の欠陥についてもう少しお読みください： https://netknights.it/en/the-problem-with-the-google-authenticator/