Authenticatiecookie met te lange geldigheid

“Onthoud mij” is een van de meest gewaardeerde functies in elke applicatie, en tegelijk een van de plaatsen waar beveiliging het stilst wordt weggegeven. Een vinkje dat de gebruiker maanden ingelogd houdt, houdt namelijk ook een aanvaller maanden ingelogd. In dit artikel leest u hoe u het comfort behoudt zonder die prijs te betalen.

Hoe lang mag een authenticatiecookie geldig zijn?

Een authenticatiecookie draagt het bewijs dat iemand is ingelogd. De vervaldatum bepaalt hoe lang dat bewijs meegaat. Een te lange geldigheid betekent dat het token nog steeds toegang geeft lang nadat de oorspronkelijke inlogpoging is vergeten, soms maanden, soms zonder enige bovengrens.

De afweging is oprecht lastig, want beide kanten zijn reëel. Een korte geldigheid dwingt gebruikers voortdurend opnieuw in te loggen, wat leidt tot zwakkere wachtwoorden, opgeslagen inloggegevens en irritatie. Een lange geldigheid is comfortabel, maar verlengt precies de periode waarin een gestolen token bruikbaar blijft.

Denk aan het verschil tussen een dagpas en een sleutel die u voor onbepaalde tijd meegeeft. Beide geven toegang; alleen bij de tweede blijft dat zo, ook nadat u vergeten bent dat u hem hebt uitgegeven.

Hoe wordt een te lang geldig authenticatiecookie misbruikt?

Kwetsbaar:

app.post('/inloggen', async (req, res) => {
  const gebruiker = await controleerInloggegevens(req.body);
  if (!gebruiker) return res.status(401).send('Onjuiste gegevens');

  req.session.userId = gebruiker.id;

  res.cookie('sid', req.sessionID, {
    httpOnly: true,
    secure: true,
    maxAge: 365 * 24 * 60 * 60 * 1000,   // een jaar
  });
  res.send('Welkom');
});

De sessie zelf is een jaar geldig. Wie het token in handen krijgt, heeft daarmee een jaar toegang. Dat token belandt intussen op meer plaatsen dan de browser van de gebruiker: in back-ups van het profiel, op een gedeelde computer waar niemand meer aan denkt, in een synchronisatiedienst tussen apparaten, of in handen van iemand die de laptop later overneemt. Er is geen tweede controlemoment waarop de applicatie zich afvraagt of deze gebruiker er nog steeds hoort te zijn.

Veilig:

const SESSIE_MAX = 8 * 60 * 60 * 1000;             // 8 uur
const ONTHOUD_MAX = 30 * 24 * 60 * 60 * 1000;      // 30 dagen

app.post('/inloggen', async (req, res) => {
  const gebruiker = await controleerInloggegevens(req.body);
  if (!gebruiker) return res.status(401).send('Onjuiste gegevens');

  req.session.regenerate(async () => {
    req.session.userId = gebruiker.id;
    req.session.gestartOp = Date.now();

    res.cookie('__Host-sid', req.sessionID, {
      httpOnly: true, secure: true, sameSite: 'strict',
      path: '/', maxAge: SESSIE_MAX,
    });

    if (req.body.onthoudMij) {
      // Apart token: alleen goed voor het starten van een nieuwe sessie
      const ruw = randomBytes(32).toString('base64url');
      await onthoudTokens.bewaar({
        gebruikerId: gebruiker.id,
        hash: sha256(ruw),                       // nooit het token zelf opslaan
        verlooptOp: Date.now() + ONTHOUD_MAX,
        apparaat: req.get('user-agent'),
      });
      res.cookie('__Host-onthoud', ruw, {
        httpOnly: true, secure: true, sameSite: 'strict',
        path: '/', maxAge: ONTHOUD_MAX,
      });
    }
    res.send('Welkom');
  });
});

De sessie is nu kort en de lange geldigheid zit in een apart token met een eigen rol. Dat token geeft geen directe toegang: het levert hooguit een nieuwe sessie op. Het is opgeslagen als hash, zodat een gelekte database de tokens niet prijsgeeft, het is gekoppeld aan een apparaat en het is intrekbaar. Wordt het gebruikt, dan geeft de server een nieuw token uit en vervalt het oude, biedt iemand daarna het oude token alsnog aan, dan is dat een duidelijk signaal dat er een kopie in omloop is.

Wat is de impact van een te lang geldig authenticatiecookie?

De ernst wordt doorgaans als laag tot middelzwaar beoordeeld, want er is geen directe aanval mogelijk: de aanvaller heeft het token nodig. Wat deze bevinding doet, is de waarde van elk ander lek vergroten.

Een sessietoken kan op veel manieren weglekken, via cross-site scripting, een onversleuteld verzoek, een logbestand, een schermafbeelding of simpelweg een computer die van eigenaar wisselt. Bij een sessie van acht uur is de schade daarvan begrensd. Bij een sessie van een jaar heeft de aanvaller alle tijd: hij kan wachten tot buiten kantooruren, rustig verkennen en op een zelfgekozen moment toeslaan, zonder dat er een tweede inlogpoging nodig is die alarm zou kunnen slaan.

Er speelt ook een organisatorische kant. Bij een lange geldigheid verliest u het overzicht over wie er nog toegang heeft. Medewerkers die zijn vertrokken, apparaten die zijn afgeschreven en accounts waarvan de rechten zijn ingetrokken houden allemaal een geldig token, tenzij u dat actief afdwingt.

Hoe spoor je een te lang geldig authenticatiecookie op?

De vervaldatum van de cookie is direct af te lezen uit de Set-Cookie-header, en dat is het startpunt. Belangrijker is de vraag of die vervaldatum ook iets betekent: een tester verwijdert de vervaldatum uit de cookie en kijkt of het token dan alsnog wordt geaccepteerd. Gebeurt dat, dan wordt de geldigheid alleen door de browser bewaakt en aan serverzijde helemaal niet.

Daarnaast wordt gekeken hoe de onthoud-mij-functie is opgezet. Is het dezelfde sessiecookie met een langere looptijd, of een apart token? Wordt dat token gehasht opgeslagen? Roteert het bij gebruik? Blijft het geldig na een wachtwoordwijziging? En wordt er bij gevoelige handelingen opnieuw om authenticatie gevraagd wanneer de sessie uit zo’n token is hersteld? AssistSec toetst die vragen als geheel, omdat een lange geldigheid met een goed opgezet, intrekbaar en roterend token verdedigbaar is, terwijl dezelfde looptijd op de sessiecookie zelf dat niet is.

Hoe voorkom je een te lang geldig authenticatiecookie?

• Houd de sessiecookie kort en verplaats een langere geldigheid naar een apart onthoud-mij-token.
• Bewaak de geldigheid aan serverzijde; vertrouw nooit op de vervaldatum in de cookie alleen.
• Sla onthoud-mij-tokens gehasht op, zodat een gelekte database geen bruikbare tokens oplevert.
• Roteer het token bij elk gebruik en trek alles in zodra een verlopen of hergebruikt token wordt aangeboden.
• Koppel het token aan een apparaat en toon de gebruiker een overzicht van actieve apparaten.
• Trek alle tokens in bij een wachtwoordwijziging, een rechtenwijziging of het blokkeren van een account.
• Vraag opnieuw om authenticatie bij gevoelige handelingen binnen een herstelde sessie.
• Stel de maximale looptijd af op de gevoeligheid van de applicatie en leg die keuze vast in uw beleid.