Applicatie gebruikt Basic Authentication

Basic Authentication is een van de oudste onderdelen van HTTP en nog steeds in gebruik: het is met één regel configuratie op te zetten en werkt overal. Die eenvoud is precies wat het ongeschikt maakt voor een moderne applicatie, want er zit geen enkele voorziening in voor wat we tegenwoordig van authenticatie verwachten. Dat verdient uitleg.

Wat is Basic Authentication?

Bij HTTP Basic Authentication stuurt de client de gebruikersnaam en het wachtwoord mee in een header, samengevoegd met een dubbele punt en daarna gecodeerd in base64. De server ontcijfert dat, controleert de combinatie en beslist. De browser onthoudt de gegevens vervolgens voor de rest van de sessie en stuurt ze bij elk volgend verzoek automatisch opnieuw mee.

Het misverstand dat het vaakst voorkomt, betreft die codering. Base64 is geen versleuteling maar een manier om gegevens in een tekstformaat te zetten; het terugrekenen is een handeling van een fractie van een seconde zonder enige sleutel. Basic am9objpQNHNzdzByZCE= is niets anders dan john:P4ssw0rd! in een andere notatie.

Een brief in blokletters is niet geheimer dan dezelfde brief in schuinschrift. De vorm is anders, de leesbaarheid niet.

Waarom is Basic Authentication ongeschikt?

Kwetsbaar:

GET /beheer/rapportage HTTP/1.1
Host: portaal.example
Authorization: Basic am9objpQNHNzdzByZCE=

Deze header gaat mee bij élk verzoek: bij elke pagina, elke afbeelding, elke API-aanroep. Dat is een wezenlijk verschil met een sessiecookie, die een tijdelijke verwijzing is naar een sessie op de server. Hier reist het wachtwoord zelf, honderden keren per bezoek.

Dat vergroot elke vorm van blootstelling. Gaat er één verzoek over een onversleutelde verbinding, dan ligt het wachtwoord op straat. Belandt de header in een logbestand van een proxy of in een foutrapportage, dan staat het wachtwoord daarin. Ook wordt het door een tussenliggend systeem opgeslagen voor foutopsporing, dan staat het daar ook.

Daarnaast ontbreekt alles wat u nodig hebt om authenticatie te beheren. Er is geen tweede factor mogelijk. Er is geen sessie die kan verlopen. Er is geen manier om de toegang in te trekken zonder het wachtwoord te wijzigen. Er is geen nette uitlogfunctie, omdat de browser de gegevens blijft meesturen. En omdat elk verzoek een volledige inlogpoging is, is het beperken van het aantal pogingen omslachtig.

Veilig:

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

  if (gebruiker.mfaActief) {
    req.session.tweedeFactorVoor = gebruiker.id;
    return res.redirect('/inloggen/verificatie');
  }
  req.session.regenerate(() => {
    req.session.userId = gebruiker.id;
    res.cookie('__Host-sid', req.sessionID, {
      httpOnly: true, secure: true, sameSite: 'strict', path: '/',
      maxAge: 30 * 60 * 1000,
    });
    res.redirect('/');
  });
});

Het wachtwoord gaat nu precies één keer over de lijn, bij het inloggen. Daarna wordt er een sessieverwijzing meegestuurd die verloopt, die u kunt intrekken, die een tweede factor toestaat en die bij uitloggen wordt vernietigd. Voor machinale koppelingen gebruikt u een token of een API-sleutel die u kunt roteren zonder iemands wachtwoord te wijzigen.

Wat is de impact van Basic Authentication?

De ernst loopt van middelzwaar tot hoog, waarbij de aanwezigheid van TLS het meest bepalend is. Zonder versleuteling is het risico direct: iedereen op het netwerkpad leest het wachtwoord mee, en omdat het bij elk verzoek meegaat, is één onderschept verzoek genoeg.

Met TLS is het grootste risico weg, maar blijven de beheerskwesties. Zonder tweede factor rust de toegang volledig op het wachtwoord, en dat wachtwoord kan elders gelekt zijn. Zonder intrekmogelijkheid houdt een medewerker toegang tot iemand het wachtwoord wijzigt. Zonder sessie is er geen timeout, dus blijft een onbeheerde browser toegang houden. Verder zonder uitlogfunctie kan de gebruiker die situatie zelf niet beëindigen.

Er is nog een aspect dat vaak wordt onderschat: doordat het wachtwoord bij elk verzoek meegaat, komt het op veel meer plaatsen terecht dan waar u het verwacht. Proxylogs, monitoringsystemen, foutrapportages en netwerkopnames bevatten dan allemaal de header, en dus het wachtwoord in een vorm die iedereen kan teruglezen.

Hoe spoor je Basic Authentication op?

De aanwezigheid is direct zichtbaar: een antwoord met 401 en een WWW-Authenticate: Basic-header, of een browservenster dat om gebruikersnaam en wachtwoord vraagt in plaats van een inlogpagina in de applicatie zelf.

Daarna wordt gekeken naar de omstandigheden. Wordt de verbinding afgedwongen over TLS, of is de dienst ook via HTTP bereikbaar? Zijn de inloggegevens gewijzigd ten opzichte van de standaard? Zijn ze gedeeld tussen meerdere personen, wat herleidbaarheid onmogelijk maakt? Wordt het aantal pogingen beperkt? Een tester controleert ook of Basic Authentication naast een moderne inlogstroom bestaat: een applicatie met een nette inlogpagina en daarnaast een API of beheerpad met Basic is een veelvoorkomend patroon, waarbij dat tweede pad de tweede factor omzeilt. AssistSec beoordeelt daarbij of het gebruik verdedigbaar is voor de betreffende toepassing, omdat een interne koppeling over TLS iets anders is dan een beheerinterface voor personen.

Hoe voorkom je Basic Authentication?

• Vervang Basic Authentication voor gebruikers door een inlogstroom met sessiebeheer en cookies.
• Dwing TLS af zolang de methode nog in gebruik is, en blokkeer elke onversleutelde route.
• Gebruik voor machinale koppelingen een token of API-sleutel die u kunt roteren.
• Wijzig standaard inloggegevens en gebruik nooit gedeelde accounts voor personen.
• Zorg dat er een tweede factor mogelijk is; dat vraagt vrijwel altijd een andere methode.
• Filter de Authorization-header uit logbestanden, monitoring en foutrapportages.
• Beperk het aantal inlogpogingen, ook bij een methode die per verzoek authenticeert.
• Controleer of er geen tweede kanaal met Basic bestaat naast uw moderne inlogstroom.
• Scherm beheerinterfaces af op netwerkniveau in plaats van uitsluitend met een wachtwoord.