「remember me」オプションに Cookie を使用する方法については、ここや他の場所をよく読みましたが、私が探しているのは、2 要素認証の成功を記録する Cookie を設計する方法です。これは、たとえば Google が行うことです。2 番目のステップが成功すると (たとえば、SMS で受け取ったコードを入力した場合)、一定期間 (たとえば 30 日間) 有効な Cookie が設定されます。 2 番目のステップはバイパスできます。これを「検証 Cookie」と呼びます。その間にログアウトしてから再度ログインすると、2番目のステップは実行されず、最初のステップのみが実行されると理解しています。(私はこれをテストしましたが、そのように見えました。)
私の質問は、このクッキーをどのように設計するかです。1 つのアイデアは、ユーザー ID と 128 ビットの乱数を Cookie に入れ、その数値をユーザー ID と共にデータベースに格納することです。これは、Charles Miller が推奨する ( http://fishbowl.pastiche.org/2004/01/19/persistent_login_cookie_best_practice/ ) 永続ログイン Cookie です。
しかし、それだけでは十分ではないと思います。問題は、ユーザーが 2 要素認証を使用しているため、2 番目のステップが成功したことを記録するために使用される Cookie が何であれ、1 要素認証の場合よりも安全である必要があることです。
私が避けたいのはこれです: クラッカーはデータベースからハッシュ化/ソルト化されたパスワードを持っており、どういうわけかパスワードを取得しています. 彼/彼女がそれだけ持っている場合、検証 Cookie にあった 128 ビットの乱数も使用できると思います。(クラッカーが別の方法でパスワードを取得し、データベースを持っていない場合、コンピューターに物理的にアクセスできない限り、検証 Cookie は安全です。私が心配しているのは、データベースが侵害された場合だけです。)
たぶん、128 ビットの乱数を暗号化するという考えはありますか? (双方向である必要があります -- ハッシュではありません。) 暗号化キーはアプリケーションからアクセスできますが、データベース資格情報は保存されている可能性があります。
私が検証 Cookie (永続的なログイン Cookie ではない) と呼んでいるものを誰かが実装し、それがどのように行われたかを教えてくれますか?
更新: これについて考えると、十分に安全だと思うものは次のとおりです: Cookie はユーザー ID と 128 ビットの乱数で構成されます - R と呼びます。
データベースにはパスワードと R が含まれており、それぞれハッシュ化およびソルト化されています (たとえば、PhPass を使用)。R は 2 番目のパスワードと見なされます。利点: 最初のパスワードが悪い場合でも (例: "password1")、R は非常に優れたパスワードです。データベースは本当にクラックできないので、心配する必要はありません。（余計な心配もしたと思います。）