Webサイトへのユーザーログイン用に「rememberme」機能を実装しました。ほとんどのアドバイスは、ユーザーIDをCookieに保存してから、推測できない長いランダムキーを用意することでした。これらの両方が一致する場合、ユーザーは認証されたと見なされます。
2つの文字列を持つことは実際に役立ちますか？より長いキーはまったく同じことをしませんか？
言い換えれば、2つのキーは1つの長いキーと同じように攻撃を受けやすいのではないでしょうか。（キーの数に関係なく、キーの全長になると思います）
注：ここでもDBクエリの効率の問題が発生する可能性があります。たとえば、DBで大きなUUIDを検索することは、小さな数を検索するほど簡単ではありません。（接線方向のメモでは、Gmailはユーザー名とともに6桁の数字を1回限りのログイントークンとして使用します。）
このSOスレッドでのそれについての確固たる議論。
...ユーザーは認証済みと見なされます。
おそらく認証済みであるが、権限が制限されていると読む必要があります。
コメントごと：1回限りの使用であり、推測が難しいため、やや安全です。そのため、Cookieが侵害された場合、攻撃者は迅速に行動する必要があります。そうしないと、正当なユーザーがログインすることでトークンが無効になりますが、ユーザーIDは長期間変更されない可能性があります。
私は暗号の専門家ではありませんが、ブルートフォース攻撃をチェックする限り、短いキー（Gmailの6桁など）を使用できるはずです。本当の脆弱性は、ユーザーがログインしたときにリッスンしている人々です（SideJackingなど）。
以前に作成したサイトuser_idでは、ユーザーのパスワードのソルトハッシュを使用しました。ユーザーを認証するために2つのフィールドを使用した主な理由は、別のテーブルを追加する手間を省いたためです（したがって、データベースの設計が複雑になります）。Cookieにuser_idも保存されているため、ユーザーテーブルでインデックス付きのルックアップを実行できます。ソルトハッシュをユーザーに効率的に一致させます。もちろん、user_idとハッシュの両方を1つの値に連結して、それをCookieに保存することもできます。
推測できないランダムな文字列がある場合は、ランダムな文字列をユーザーIDに関連付けて、その特定のユーザーをもう一度検索するための別のテーブルが必要になります。