V3.2.2 - Session token length only 8 bytes...

[TheAxZim]

Brought to attention by @execjosh

According to: https://github.com/OWASP/ASVS/blob/master/4.0/en/0x12-V3-Session-management.md

#	Description
3.2.2	Verify that session tokens possess at least 64 bits of entropy. (C6)

Aren't these values too short? That's just 8 bytes....

According to OWASPs own guide: https://owasp.org/www-community/vulnerabilities/Insufficient_Session-ID_Length

Session identifiers should be at least 128 bits long to prevent brute-force session guessing attacks.

The WebLogic deployment descriptor should specify a session identifier length of at least 128 bits. A shorter session identifier leaves the application open to brute-force session guessing attacks.

With a 64 bit session identifier, assume 32 bits of entropy. For a large web site, assume that the attacker can try 1,000 guesses per second and that there are 10,000 valid session identifiers at any given moment. Given these assumptions, the expected time for an attacker to successfully guess a valid session identifier is about 7 minutes. (32bit = 4294967296 / 10.000 = 429496. At 1000 attempts per second that is 429 seconds or 7.15 minutes.)

Recommendation: Update to a minimum of 128 bits, or a higher standard of 256 bits.

[jmanico]

Good argument here +1

-- Jim Manico @Manicode

On Aug 6, 2020, at 7:01 AM, Azeem Ilyas notifications@github.com wrote:

 Brought to attention by @execjosh

According to: https://github.com/OWASP/ASVS/blob/master/4.0/en/0x12-V3-Session-management.md

Description

3.2.2 Verify that session tokens possess at least 64 bits of entropy. (C6) Aren't these values too short? That's just 8 bytes....

According to OWASPs own guide: https://owasp.org/www-community/vulnerabilities/Insufficient_Session-ID_Length

Session identifiers should be at least 128 bits long to prevent brute-force session guessing attacks.

The WebLogic deployment descriptor should specify a session identifier length of at least 128 bits. A shorter session identifier leaves the application open to brute-force session guessing attacks.

With a 64 bit session identifier, assume 32 bits of entropy. For a large web site, assume that the attacker can try 1,000 guesses per second and that there are 10,000 valid session identifiers at any given moment. Given these assumptions, the expected time for an attacker to successfully guess a valid session identifier is about 7 minutes. (32bit = 4294967296 / 10.000 = 429496. At 1000 attempts per second that is 429 seconds or 7.15 minutes.)

Recommendation: Update to a minimum of 128 bits, or a higher standard of 256 bits.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[Racater]

You're right, 64 bit is not enough to be really secure and is inconsistent with the OWASP web guidelines. The 64 bit requirement is there to be compliant with NIST 800-63b. As written in the document, one of the objective of OWASP ASVS 4.0 is to minimize the number of standards and, to do so, has adopted the NIST 800-63b standard.

So either there is a modification of the OWASP web guidelines, or the recommendations deviates from each other.

[TomTervoort]

The referenced guide also states:

Now assume a 128 bit session identifier that provides 64 bits of entropy. With a very large web site, an attacker might try 10,000 guesses per second with 100,000 valid session identifiers available to be guessed. Given these assumptions, the expected time for an attacker to successfully guess a valid session identifier is greater than 292 years.

So the guide actually does allow session identifiers with 64 bits of entropy. It just presumes that a session ID with a 64-bit length actually contains 32 bits of entropy (due to hex encoding, I assume).

I personally also agree with the guide that a session identifier that is some encoding of 8 cryptographically generated random bytes is perfectly fine. You can not brute-force session identifiers offline, nor have to worry about birthday attacks, so using 128or more bits should not be necessary.

[jmanico]

“bare minimum” recomendations concearn me. I suggest we strive to make suggestions that will stand the test of time so please try to keep away from bare minimum session size. Java and other languages have at least 160 bit session id’s. Let’s keep our recomendation at (at least) 128 bits, minimum, please.

-- Jim Manico @Manicode

On Sep 22, 2020, at 1:28 AM, Tom Tervoort notifications@github.com wrote:

 The referenced guide also states:

Now assume a 128 bit session identifier that provides 64 bits of entropy. With a very large web site, an attacker might try 10,000 guesses per second with 100,000 valid session identifiers available to be guessed. Given these assumptions, the expected time for an attacker to successfully guess a valid session identifier is greater than 292 years.

So the guide actually does allow session identifiers with 64 bits of entropy. It just presumes that a session ID with a 64-bit length actually contains 32 bits of entropy (due to hex encoding, I assume).

I personally also agree with the guide that a session identifier that is some encoding of 8 cryptographically generated random bytes is perfectly fine. You can not brute-force session identifiers offline, nor have to worry about birthday attacks, so using 128or more bits should not be necessary.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.

[jmanico]

Im ready for a PR bumping this to 128 please! cc @TheAxZim or @Racater

[TheAxZim]

@jmanico Sorry for the late reply. Since Josh is the original discoverer, he has raised a PR at #972 Thanks ~

[jmanico]

This is merged and I also added the modified flag here https://github.com/OWASP/ASVS/commit/46318d2a42778eef621cfe7b659c30e29aa8c690

Closing issue now :) please re-open if this was done in haste.

[execjosh]

Thank you!