セッションをCookieに保存する場合は、秘密で暗号化する必要があります。そうしないと、悪意のあるクライアントがセッションを自由に変更する可能性があります。この設計は、一般的に議論されている多くの理由でまだ悪いです。
ただし、サーバーにセッションを保存する場合（Rack：Session：Dalliを介してMemcacheストアを使用する場合）、クライアントが取得するのは、サーバーがストアからセッションを検索するために使用するキーを持つCookieだけであることを理解しています。私はまだセッションシークレットを設定しています。しかし、私はそれがもう何をするのか理解していません。
大きな乱数を暗号化すると、本質的に別の大きな乱数になります。言い換えると、情報に起因する意味がない場合（単なる乱数）、暗号化によるセキュリティ上の利点はありません。保存しているIDに、特定のビットセットやIDの特定のサブセットのみが使用されているなどの情報が埋め込まれている場合は、暗号化が役立ちます。
セッションIDの長さは重要です。明らかに、IDが長いほど、ブルートフォースに対する耐性が高くなります。セッション数により、有効なセッションIDを見つけるために必要なブルートフォース攻撃の回数が減るため、予想される同時ユーザーセッション数も要因になります。たとえば、2つの同時セッションにより、IDの有効強度が1ビット減少します（128ビットキーは、1セッションのみの場合の127ビットキーと同じくらい有効になります）。（たとえば）1,000,000の同時セッションを持つAmazon規模のWebサイトは、セッションキーの強度の20ビットを事実上失います。
ブルートフォース攻撃から防御する必要がある場合は、ミドルウェアを実装してそれをチェックします。アプリケーション固有の文字列などの情報をセッションIDに追加すると、ブルートフォース攻撃の検出が容易になります（セッションIDの暗号化が必要になります）。これはキー自体のセキュリティを強化するものではなく、不適切なセッションIDが提示されたときにアプリが何らかのアクションを実行しない限り、基本的に無駄な労力であることに注意してください。
何をするにしても、SSLを使用し、Cookieをhttpsのみに設定してください。セッションサーバー側をタイムアウトし、Cookieの有効期限とクライアントブラウザの善意に依存しないでください。
TL; DR：セッションIDストレージにCookieのみを使用する場合、適切なRNGが使用されていれば、暗号化は必要ありません。SSLを使用して、Cookieの安全な属性を設定します。