3 added 2 characters in body
source | link

My question is: What are advantages of multiple valid CSRF tokens?

In general, there's no particular security advantage... the important bit about a token is when and how it becomes invalid (as in the previous discussion about whether a token becomes invalid after a single request or not). When and how many tokens are generated is more of an implementation detail:

If you implement CSRF tokens as random values stored persistently (the 'synchroniser token' pattern), you don't really want to store more than one token per session, as it will take more and more database bandwidth to do so. So it's natural in this model to have just a single token stored as an attribute on the sesionsession.

If you implement CSRF tokens as a signature (typically: HMAC) over the session assertion then you're validating that token by checking the signature with your application's secret key, so you don't need to store the token at the server side at all. In this model it is cheap to generate/sign a new token every time, and as the tokens typically include a timestamp and a random salt, they'll be different each time.

The usual advantage of the signature method is that you don't need storage, so it can potentially be part of a sessionlesssession-less access control scheme. The disadvantage is you need to manage the secret key safely. (But often you already have that burden anyway.)

However...

So why did Connect developers desidedecide to generate a new token on each request

Unclear. Judging by the code on the linked page Connect has a random value stored on the session, but then the tokens it issues are signatures over this random value and another per-token random value.

This doesn't appear to have any advantages over plain synchroniser-token: you still have to store session attributes, and the issued tokens aren't limited by any other signed restrictions (eg expiry timestamp or revokability). So knowledge of the issued token grants the same access as knowledge of the stored random value. They are fully equivalent, so there's no obvious point in having the varying issued tokens at all, you could just issue the stored random value with no security downside.

My question is: What are advantages of multiple valid CSRF tokens?

In general, there's no particular security advantage... the important bit about a token is when and how it becomes invalid (as in the previous discussion about whether a token becomes invalid after a single request or not). When and how many tokens are generated is more of an implementation detail:

If you implement CSRF tokens as random values stored persistently (the 'synchroniser token' pattern), you don't really want to store more than one token per session, as it will take more and more database bandwidth to do so. So it's natural in this model to have just a single token stored as an attribute on the sesion.

If you implement CSRF tokens as a signature (typically: HMAC) over the session assertion then you're validating that token by checking the signature with your application's secret key, so you don't need to store the token at the server side at all. In this model it is cheap to generate/sign a new token every time, and as the tokens typically include a timestamp and a random salt, they'll be different each time.

The usual advantage of the signature method is that you don't need storage, so it can potentially be part of a sessionless access control scheme. The disadvantage is you need to manage the secret key safely. (But often you already have that burden anyway.)

However...

So why did Connect developers deside to generate a new token on each request

Unclear. Judging by the code on the linked page Connect has a random value stored on the session, but then the tokens it issues are signatures over this random value and another per-token random value.

This doesn't appear to have any advantages over plain synchroniser-token: you still have to store session attributes, and the issued tokens aren't limited by any other signed restrictions (eg expiry timestamp or revokability). So knowledge of the issued token grants the same access as knowledge of the stored random value. They are fully equivalent, so there's no obvious point in having the varying issued tokens at all, you could just issue the stored random value with no security downside.

My question is: What are advantages of multiple valid CSRF tokens?

In general, there's no particular security advantage... the important bit about a token is when and how it becomes invalid (as in the previous discussion about whether a token becomes invalid after a single request or not). When and how many tokens are generated is more of an implementation detail:

If you implement CSRF tokens as random values stored persistently (the 'synchroniser token' pattern), you don't really want to store more than one token per session, as it will take more and more database bandwidth to do so. So it's natural in this model to have just a single token stored as an attribute on the session.

If you implement CSRF tokens as a signature (typically: HMAC) over the session assertion then you're validating that token by checking the signature with your application's secret key, so you don't need to store the token at the server side at all. In this model it is cheap to generate/sign a new token every time, and as the tokens typically include a timestamp and a random salt, they'll be different each time.

The usual advantage of the signature method is that you don't need storage, so it can potentially be part of a session-less access control scheme. The disadvantage is you need to manage the secret key safely. (But often you already have that burden anyway.)

However...

So why did Connect developers decide to generate a new token on each request

Unclear. Judging by the code on the linked page Connect has a random value stored on the session, but then the tokens it issues are signatures over this random value and another per-token random value.

This doesn't appear to have any advantages over plain synchroniser-token: you still have to store session attributes, and the issued tokens aren't limited by any other signed restrictions (eg expiry timestamp or revokability). So knowledge of the issued token grants the same access as knowledge of the stored random value. They are fully equivalent, so there's no obvious point in having the varying issued tokens at all, you could just issue the stored random value with no security downside.

2 added 109 characters in body
source | link

My question is: What are advantages of multiple valid CSRF tokens?

In general, there's no particular security advantage;advantage... the important bit about a token is when and how it becomes invalid, (as in the previous discussion about whether a token becomes invalid after a single request or not). When and how many tokens are generated, whichgenerated is more of an implementation detail:

If you implement CSRF tokens as random values stored persistently (the 'synchroniser token' pattern), you don't really want to store more than one token per session, as it will take more and more database bandwidth to do so. So it's natural in this model to have just a single token stored as an attribute on the sesion.

If you implement CSRF tokens as a signature (typically: HMAC) over the session assertion then you're validating that token by checking the signature with your application's secret key, so you don't need to store the token at the server side at all. In this model it is cheap to generate/sign a new token every time, and as the tokens typically include a timestamp and a random salt, they'll be different each time.

The usual advantage of the signature method is that you don't need storage, so it can potentially be part of a sessionless access control scheme. The disadvantage is you need to manage the secret key safely. (But often you already have that burden anyway.)

However...

So why did Connect developers deside to generate a new token on each request

Unclear. Judging by the code on the linked page Connect has a random value stored on the session, but then the tokens it issues are signatures over this random value and another per-token random value.

This doesn't appear to have any advantages over plain synchroniser-token: you still have to store session attributes, and the issued tokens aren't limited by any other signed restrictions (eg expiry timestamp or revokability). So knowledge of the issued token grants the same access as knowledge of the stored random value. They are fully equivalent, so there's no obvious point in having the varying issued tokens at all, you could just issue the stored random value with no security downside.

My question is: What are advantages of multiple valid CSRF tokens?

In general, there's no particular security advantage; the important bit about a token is when and how it becomes invalid, not how many are generated, which is more of an implementation detail:

If you implement CSRF tokens as random values stored persistently (the 'synchroniser token' pattern), you don't really want to store more than one token per session, as it will take more and more database bandwidth to do so. So it's natural in this model to have just a single token stored as an attribute on the sesion.

If you implement CSRF tokens as a signature (typically: HMAC) over the session assertion then you're validating that token by checking the signature with your application's secret key, so you don't need to store the token at the server side at all. In this model it is cheap to generate/sign a new token every time, and as the tokens typically include a timestamp and a random salt, they'll be different each time.

The usual advantage of the signature method is that you don't need storage, so it can potentially be part of a sessionless access control scheme. The disadvantage is you need to manage the secret key safely. (But often you already have that burden anyway.)

However...

So why did Connect developers deside to generate a new token on each request

Unclear. Judging by the code on the linked page Connect has a random value stored on the session, but then the tokens it issues are signatures over this random value and another per-token random value.

This doesn't appear to have any advantages over plain synchroniser-token: you still have to store session attributes, and the issued tokens aren't limited by any other signed restrictions (eg expiry timestamp or revokability). So knowledge of the issued token grants the same access as knowledge of the stored random value. They are fully equivalent, so there's no obvious point in having the varying issued tokens at all, you could just issue the stored random value with no security downside.

My question is: What are advantages of multiple valid CSRF tokens?

In general, there's no particular security advantage... the important bit about a token is when and how it becomes invalid (as in the previous discussion about whether a token becomes invalid after a single request or not). When and how many tokens are generated is more of an implementation detail:

If you implement CSRF tokens as random values stored persistently (the 'synchroniser token' pattern), you don't really want to store more than one token per session, as it will take more and more database bandwidth to do so. So it's natural in this model to have just a single token stored as an attribute on the sesion.

If you implement CSRF tokens as a signature (typically: HMAC) over the session assertion then you're validating that token by checking the signature with your application's secret key, so you don't need to store the token at the server side at all. In this model it is cheap to generate/sign a new token every time, and as the tokens typically include a timestamp and a random salt, they'll be different each time.

The usual advantage of the signature method is that you don't need storage, so it can potentially be part of a sessionless access control scheme. The disadvantage is you need to manage the secret key safely. (But often you already have that burden anyway.)

However...

So why did Connect developers deside to generate a new token on each request

Unclear. Judging by the code on the linked page Connect has a random value stored on the session, but then the tokens it issues are signatures over this random value and another per-token random value.

This doesn't appear to have any advantages over plain synchroniser-token: you still have to store session attributes, and the issued tokens aren't limited by any other signed restrictions (eg expiry timestamp or revokability). So knowledge of the issued token grants the same access as knowledge of the stored random value. They are fully equivalent, so there's no obvious point in having the varying issued tokens at all, you could just issue the stored random value with no security downside.

1
source | link

My question is: What are advantages of multiple valid CSRF tokens?

In general, there's no particular security advantage; the important bit about a token is when and how it becomes invalid, not how many are generated, which is more of an implementation detail:

If you implement CSRF tokens as random values stored persistently (the 'synchroniser token' pattern), you don't really want to store more than one token per session, as it will take more and more database bandwidth to do so. So it's natural in this model to have just a single token stored as an attribute on the sesion.

If you implement CSRF tokens as a signature (typically: HMAC) over the session assertion then you're validating that token by checking the signature with your application's secret key, so you don't need to store the token at the server side at all. In this model it is cheap to generate/sign a new token every time, and as the tokens typically include a timestamp and a random salt, they'll be different each time.

The usual advantage of the signature method is that you don't need storage, so it can potentially be part of a sessionless access control scheme. The disadvantage is you need to manage the secret key safely. (But often you already have that burden anyway.)

However...

So why did Connect developers deside to generate a new token on each request

Unclear. Judging by the code on the linked page Connect has a random value stored on the session, but then the tokens it issues are signatures over this random value and another per-token random value.

This doesn't appear to have any advantages over plain synchroniser-token: you still have to store session attributes, and the issued tokens aren't limited by any other signed restrictions (eg expiry timestamp or revokability). So knowledge of the issued token grants the same access as knowledge of the stored random value. They are fully equivalent, so there's no obvious point in having the varying issued tokens at all, you could just issue the stored random value with no security downside.