Lesson test: Sessions and cookies

Sign in

Libre University uses your GitHub account. Signing in is only needed to sit a final test, so the score is kept on your profile.

Sessions and cookies

1.[3p]
Match each cookie attribute to what it stops.

HttpOnly
Secure
SameSite=Lax
__Host- prefix

a cross-site form post arriving with the cookie attached
the cookie travelling over a forced plain HTTP request
injected script reading the value through document.cookie
any subdomain reading or overwriting the cookie

Show the answer

HttpOnly: injected script reading the value through document.cookie Secure: the cookie travelling over a forced plain HTTP request SameSite=Lax: a cross-site form post arriving with the cookie attached __Host- prefix: any subdomain reading or overwriting the cookie

2.[3p]
Why does the sessions table store `SHA-256(token)` rather than the token?

A leaked table then hands the attacker nothing usable, since the digest cannot be turned back into a token

Correct

SHA-256 is faster to index than a random string

The answer is: A leaked table then hands the attacker nothing usable, since the digest cannot be turned back into a token

It stops an attacker from guessing the token over the network

The answer is: A leaked table then hands the attacker nothing usable, since the digest cannot be turned back into a token

It lets the same token be reused across subdomains

The answer is: A leaked table then hands the attacker nothing usable, since the digest cannot be turned back into a token

3.[3p]
Why is a fast hash correct for a session token but wrong for a password?

A session token is drawn uniformly from a 256-bit space, so there is no candidate list to guess through

Correct

A session token is shorter, so hashing it costs less

The answer is: A session token is drawn uniformly from a 256-bit space, so there is no candidate list to guess through

Session tokens are salted and passwords are not

The answer is: A session token is drawn uniformly from a 256-bit space, so there is no candidate list to guess through

The session hash is verified once per login rather than once per request

The answer is: A session token is drawn uniformly from a 256-bit space, so there is no candidate list to guess through

4.[2p]
Rotating the session token at the moment a user signs in is what defeats session fixation.

True

Correct

False

The answer is: True

5.[3p]
With $k$ identifiers of $b$ bits, expected collisions are about $k^{2} / 2^{b + 1}$ . How many bits does a token need for a billion of them to give roughly a 3 percent chance of a collision?

CorrectNot quite: 64

6.[3p]
Which of these are real problems with keeping a session token in `localStorage`?

Select all that apply

Any script running on the origin can read it, and no attribute exists to prevent that

Correct

Once exfiltrated it can be replayed from the attacker's own machine with no origin restriction

Correct

It trades a risk with a cheap known defence for one with no defence

Correct

The browser sends it automatically on cross-site requests

The answer is: Any script running on the origin can read it, and no attribute exists to prevent that, Once exfiltrated it can be replayed from the attacker's own machine with no origin restriction, It trades a risk with a cheap known defence for one with no defence

7.[3p]
Put these in the order the server performs them on a successful password login.

Generate 32 random bytes as the token
Set the cookie carrying the token
Verify the password against the stored hash
Insert a session row keyed by the hash of the token

Show the answer

b, d, c, a

8.[3p]
A cookie is named `__Host-session`. What must be true for the browser to accept it?

Secure is set, Path is /, and there is no Domain attribute

Correct

Domain is set to the parent domain and Secure is set

The answer is: Secure is set, Path is `/`, and there is no Domain attribute

HttpOnly and SameSite=Strict are both set

The answer is: Secure is set, Path is `/`, and there is no Domain attribute

Max-Age is under one hour

The answer is: Secure is set, Path is `/`, and there is no Domain attribute

9.[2p]
Which expiry clock, if omitted, lets a stolen token stay valid forever so long as it is used regularly?

CorrectNot quite: absolute

1.[3p] Match each cookie attribute to what it stops.

2.[3p] Why does the sessions table store SHA-256(token) rather than the token?

3.[3p] Why is a fast hash correct for a session token but wrong for a password?

4.[2p] Rotating the session token at the moment a user signs in is what defeats session fixation.

5.[3p] With k identifiers of b bits, expected collisions are about k2/2b+1. How many bits does a token need for a billion of them to give roughly a 3 percent chance of a collision?

6.[3p] Which of these are real problems with keeping a session token in localStorage?

7.[3p] Put these in the order the server performs them on a successful password login.

8.[3p] A cookie is named __Host-session. What must be true for the browser to accept it?

9.[2p] Which expiry clock, if omitted, lets a stolen token stay valid forever so long as it is used regularly?

1.[3p]
Match each cookie attribute to what it stops.

2.[3p]
Why does the sessions table store `SHA-256(token)` rather than the token?

3.[3p]
Why is a fast hash correct for a session token but wrong for a password?

4.[2p]
Rotating the session token at the moment a user signs in is what defeats session fixation.

5.[3p]
With $k$ identifiers of $b$ bits, expected collisions are about $k^{2} / 2^{b + 1}$ . How many bits does a token need for a billion of them to give roughly a 3 percent chance of a collision?

6.[3p]
Which of these are real problems with keeping a session token in `localStorage`?

7.[3p]
Put these in the order the server performs them on a successful password login.

8.[3p]
A cookie is named `__Host-session`. What must be true for the browser to accept it?

9.[2p]
Which expiry clock, if omitted, lets a stolen token stay valid forever so long as it is used regularly?