ContentsThe library

Proving Who You Are

The Thing the Browser Carries

Last timeThe First Proof

A session is a cached answer to the question of who you are. This lesson designs one: what the identifier must survive, where it may be kept, and how long it should live.

A cached answer

A session identifier is a pointer to a recorded fact: this identity was

proved, at this time, by this method. The browser sends it with every

request, and your system looks up the fact instead of asking the person

again.

The consequence is simple and worth saying bluntly. Anybody holding the

identifier is the user, for as long as it is valid. It is not a weaker form

of the password, it is the password with a shorter life, and it is easier to

obtain because it travels on every request and sits in a browser rather than

in somebody's head.

So the three questions that follow are all questions about protecting a

credential: how hard is it to guess, where does it live, and how long is it

good for.

Unguessable against everybody at once

The first instinct is to ask how long it would take to guess one particular

session. That is the wrong question, because an attacker guessing at random

is not aiming at one session, they are aiming at all of them.

FIG 1The chance one random guess lands on a live session
chance a single guess hits some live session
sessions currently active
size of the identifier space
The numerator is the part people forget. A service with ten million live sessions is ten million times easier to hit than a service with one, so the identifier has to be sized against the busiest moment the service will ever have rather than against a single account.

With 128 bits from a cryptographic source the space is about 3.4 followed by

38 zeros, and ten million live sessions give a chance per guess of roughly

three in a hundred thousand billion billion billion. At a million guesses a

second that is not a defence that erodes, it is a defence that does not

apply.

The length is the easy half. The harder half is the source. An identifier

produced by a general-purpose random number generator, the kind used for

shuffling a list, is predictable from a few observed outputs, and the

arithmetic above becomes irrelevant because the attacker is no longer

guessing. The requirement is a cryptographic generator, and the practical

version of this rule is to use the one your platform provides for this

purpose and never a convenience function.

Two further properties come free with a long random value and are worth

keeping. It should carry no meaning, so nothing can be learned from it or

constructed. And it should be issued fresh at every sign-in, which matters

later: a session identifier that existed before the password was entered can

be planted by somebody else.

The lesson stops here

5 more paragraphs to go

You have read the opening. The rest of the argument, the problems that check whether it landed, and the lines worth keeping at the end all come with a plan.

The first lesson of every course in the library reads the whole way through, free, so you can see exactly what the rest of them are.

See the planThe contents

This is the reading half

Starting the course gives you your own copy of it. Every idea on every page has problems standing under it, marked with a reason rather than a tick, and any sentence you do not believe can be opened and argued with. None of that can happen on a page nobody owns.

The contents

The rest of this course

  1. 01Who You Are, What You May Do, and Who Remembers
  2. 02What Each Kind of Proof Actually Resistsopening only
  3. 03The Thing the Browser Carriesyou are here
  4. 04The Token That Answers for Itselfopening only
  5. 05Two Tokens Beat Oneopening only
  6. 06Borrowing Somebody Elses Proofopening only
  7. 07The Request Your Browser Sent for Somebody Elseopening only
  8. 08Making Somebody Stop Being Signed Inopening only

Read alongside