Replay Detection

[Starting with the .NET Framework 4.5, Windows Identity Foundation (WIF) has been fully integrated into the .NET Framework. The version of WIF addressed by this topic, WIF 3.5, is deprecated and should only be used when developing against the .NET Framework 3.5 SP1 or the .NET Framework 4. For more information about WIF in the .NET Framework 4.5, also known as WIF 4.5, see the Windows Identity Foundation documentation in the .NET Framework 4.5 Development Guide.]

When a client first tries to access a protected resource that is hosted by a relying party, it must first authenticate itself to a security token service (STS) that is trusted by the relying party. The STS then issues a security token to the client. The client presents this token to the relying party, which then grants the client access to the protected resource. In a typical passive federation scenario, the STS token is a bearer token. This means that an attacker could intercept the STS token by using a man-in-the-middle (MITM) attack or an insecure path to the Web site, and then use the token to impersonate the client to the Web site.

As another example, suppose that a user opens a browser on a public kiosk, logs on to a bank account using the bank’s Web site, logs off and leaves, but does not close the browser. The response to the user’s logon page, which contains the STS token, is still in the browser’s history. Another person could then browse back to that response page and replay it, which would repost the STS token to the bank’s Web site.

To prevent this, WIF has a replay detection cache specifically for STS bearer tokens, which is just a cache of previously used STS tokens. When the client first authenticates to the RP using the STS token, it receives a session security token which it uses to authenticate to the RP for any additional requests. It does this over SSL so that the session security token cannot be stolen. If a client or an attacker tries to authenticate to the relying party with an STS token that the client has used already, the relying party can look up the STS token in the replay cache and refuse the request.

This cache does not guarantee that a token can never be replayed. It performs best effort detection based on the size of the cache, the expiry time of the STS token, and the rate of unique authentication requests received by the RP. It is strongly recommended that you tune the cache size and STS token expiry time for your RP to get the right balance between performance and security.