Wachtwoordvelden worden automatisch aangevuld

Deze bevinding komt in vrijwel elk rapport voor en wordt bijna even vaak verkeerd begrepen. Het advies om automatisch aanvullen op wachtwoordvelden uit te zetten stamt uit een tijd zonder wachtwoordmanagers, en het onverkort toepassen ervan maakt uw beveiliging tegenwoordig zwakker in plaats van sterker. De nuance zit in het soort veld, niet in de functie zelf.

Wat doet het autocomplete-attribuut?

Browsers kunnen ingevulde gegevens onthouden en later opnieuw invullen. Voor wachtwoorden gebeurt dat via de ingebouwde wachtwoordmanager of via een externe. Met het attribuut autocomplete op een invoerveld geeft u aan wat de browser met dat veld mag doen.

Het klassieke advies luidde: zet dat uit op wachtwoordvelden, want een opgeslagen wachtwoord kan door iemand anders worden gebruikt. Dat advies is losgelaten, en om een goede reden. Wie het gebruik van wachtwoordmanagers bemoeilijkt, krijgt gebruikers die hun wachtwoorden zelf moeten onthouden, en die kiezen dan korte, voorspelbare of hergebruikte wachtwoorden. De winst van het ene risico weegt niet op tegen de verslechtering van het andere.

Wie een sleutelkastje verbiedt omdat het opengebroken kan worden, krijgt bewoners die hun sleutel onder de mat leggen. Het oorspronkelijke risico is weg en het nieuwe is groter.

Wat is dan wél juist?

Kwetsbaar:

<!-- Beheerder stelt een wachtwoord in voor een andere gebruiker -->
<form action="/beheer/gebruiker/wachtwoord" method="post">
  <input name="gebruiker" value="j.dekker@bedrijf.nl">
  <input name="wachtwoord" type="password">
  <button>Instellen</button>
</form>

Dit is het geval waarin automatisch aanvullen wél problematisch is. De browser van de beheerder ziet een wachtwoordveld en biedt aan het opgeslagen wachtwoord van de beheerder zelf in te vullen. Wordt dat over het hoofd gezien, dan krijgt de gebruiker het wachtwoord van de beheerder toegewezen, met alle gevolgen van dien. De manager kan het bovendien opslaan onder de verkeerde naam, waardoor gegevens door elkaar gaan lopen.

Veilig:

<!-- Inloggen: aanvullen juist wél toestaan -->
<form action="/inloggen" method="post">
  <input name="email" type="email" autocomplete="username">
  <input name="wachtwoord" type="password" autocomplete="current-password">
  <button>Inloggen</button>
</form>

<!-- Nieuw wachtwoord kiezen: manager stelt een sterk wachtwoord voor -->
<form action="/account/wachtwoord" method="post">
  <input name="huidig" type="password" autocomplete="current-password">
  <input name="nieuw" type="password" autocomplete="new-password">
  <button>Wijzigen</button>
</form>

<!-- Wachtwoord voor iemand anders: hier hoort aanvullen niet -->
<form action="/beheer/gebruiker/wachtwoord" method="post">
  <input name="wachtwoord" type="password" autocomplete="off">
  <button>Instellen</button>
</form>

Het verschil zit in de bedoeling van het veld. Op het inlogformulier helpt aanvullen, en de expliciete waarden zorgen dat managers de velden correct herkennen. Bij het kiezen van een nieuw wachtwoord geeft new-password de manager het signaal om een sterk wachtwoord voor te stellen in plaats van het oude in te vullen. Bovendien bij een veld dat het wachtwoord van iemand anders betreft, hoort aanvullen niet thuis.

Wat is de impact van automatisch aangevulde wachtwoordvelden?

De ernst is laag, en dat is in vrijwel alle gevallen terecht. Er is een specifieke situatie voor nodig: iemand anders moet fysieke of externe toegang hebben tot het apparaat en het profiel van de gebruiker. Wie dat heeft, heeft doorgaans al ernstiger mogelijkheden.

De situatie waarin het wel iets betekent, is de gedeelde werkplek. Op een balie, in een productieomgeving of in een gezamenlijke ruimte, waar meerdere personen hetzelfde profiel gebruiken, kan een opgeslagen wachtwoord door de volgende gebruiker worden benut. Dat is echter eerder een probleem van gedeelde profielen dan van het formulier.

De omgekeerde kant weegt in de praktijk zwaarder. Een applicatie die het gebruik van een wachtwoordmanager bemoeilijkt (door aanvullen te blokkeren, door plakken te verhinderen of door een lage maximumlengte te hanteren) krijgt aantoonbaar zwakkere wachtwoorden. Dat effect raakt elke gebruiker, elke dag, en niet alleen degenen die een apparaat delen.

Hoe spoor je automatisch aangevulde wachtwoordvelden op?

Een tester bekijkt de wachtwoordvelden in de applicatie en let op de attributen: staat er een expliciete autocomplete-waarde, en past die bij de bedoeling van het veld? Ontbreekt hij op het inlogformulier, dan is dat eerder een gemiste kans dan een risico.

De aandacht gaat vooral naar de velden waar het wél om vraagt: beheerschermen waarin een wachtwoord voor een ander wordt ingesteld, formulieren op gedeelde apparaten, en velden waarin een geheim wordt ingevoerd dat niet het eigen wachtwoord is: een API-sleutel, een pincode, een tweefactorcode. Daarnaast wordt gekeken of de applicatie het gebruik van wachtwoordmanagers juist tegenwerkt, bijvoorbeeld door plakken te blokkeren of door velden zo op te bouwen dat een manager ze niet herkent. AssistSec beoordeelt deze bevinding in die context, omdat het onverkort uitzetten van aanvullen tegenwoordig eerder een aandachtspunt is dan een aanbeveling.

Hoe voorkom je automatisch aangevulde wachtwoordvelden?

• Laat automatisch aanvullen op inlogformulieren aan staan en gebruik autocomplete="current-password".
• Markeer het gebruikersnaamveld met autocomplete="username", zodat managers de velden correct koppelen.
• Gebruik autocomplete="new-password" op velden waarin een nieuw wachtwoord wordt gekozen.
• Zet autocomplete="off" op velden waarin een wachtwoord voor een andere gebruiker wordt ingesteld.
• Sta plakken toe en hanteer een ruime maximumlengte, zodat wachtwoordmanagers bruikbaar blijven.
• Vermijd gedeelde profielen op gemeenschappelijke werkplekken; dat lost het onderliggende probleem op.
• Stel op gedeelde apparaten een korte sessietimeout en automatische schermvergrendeling in.
• Beschouw dit als een aandachtspunt in de vormgeving van uw formulieren, niet als een beveiligingsmaatregel op zichzelf.