tkt auth cookieは、ユーザー名とオプションでタイムスタンプを含むいくつかの情報の安全なハッシュですが、ユーザーパスワードは含まれません。認証されると、そのようなCookieをユーザーに提供し、ユーザーが戻るたびに、ユーザー名を再度抽出して、それが同じユーザーであることを確認します。
ただし、このCookieを安全に保つには、サーバー側のシークレットが必要です。その秘密を所有しているサーバーのみがこれらのCookieを作成できます。攻撃者がそれを入手した場合、これらのユーザーのパスワードを知らなくても、任意のユーザーの認証Cookieを生成できます。
ポリシーのsecretパラメーターは、そのサーバー側のシークレットです。サーバーのマスターパスワードのようなものです。サイトで複数のプロセスを実行する場合（およびWSGIを使用する場合は通常実行します）、各プロセスがCookieを検証できるように、プロセス全体で一貫性を保つ必要があります。構成ファイル、ソースコード、またはデータベースで指定できます。それは、必要な柔軟性、セキュリティポリシー、および他のシステムと秘密を共有する必要があるかどうかによって異なります。
同じ標準を使用して、ユーザーを認証する必要があるドメイン内の他のシステムとシークレットを共有できます。mod_auth_tktたとえば、Apacheにはモジュールがあり、Ploneは同じ標準を使用し、シークレットを共有することで、異なるWebアプリケーション間でユーザーにシングルサインオンを提供できます。
シークレットを変更すると、既存のセッションが無効になり、ユーザーは再認証する必要があることに注意してください。
いずれにせよ、既存のCookieの寿命は限られている可能性があります。timeoutポリシーでパラメータを設定した場合、埋め込まれたタイムスタンプは、有効として受け入れられる期間を制限します。再発行時間と組み合わせてタイムアウトを設定することをお勧めします。タイムアウト内にアプリケーションに再アクセスしたユーザーには、セッションを最新の状態に保つために、新しいタイムスタンプを持つ新しいCookieが再発行されます。そうすれば、ユーザーが戻ってこない場合、セッションCookieは自動的に期限切れになり、攻撃者が後でCookieを再利用することはできません。このreissueパラメーターを使用すると、新しいトークンが発行される速度を制御できます。数秒以内にサーバーに再度アクセスしてreissueも、新しいトークンは生成されません。
私が覚えている限り、秘密のパラメータは、Cookieを作成するためのソルトとして使用される文字列です。好きなものを入れることができます。設定ファイルに含めるだけで十分です。データベースに保存するのはやり過ぎかもしれませんが、作成されたものを無効にしたい場合は、シークレットを変更すると、その変更前に作成されたすべてのCookieとセッションが無効になると思います。