Ga naar hoofdinhoud

Wachtwoorden: in de praktijk

Met Argon2 uit les 7 tot en met 10 bewaar je wachtwoorden zoals het hoort. Een echte site doet nog meer, omdat een aanvaller niet alleen op de database uit is: hij kan ook heel vaak proberen in te loggen, of een wachtwoord gebruiken dat hij bij een andere site heeft buitgemaakt.

Wat jij zelf doet​

Goede wachtwoorden toestaan​

Veel sites eisen een hoofdletter, een cijfer en een leesteken, en een nieuw wachtwoord elke drie maanden. Dat levert wachtwoorden op als Welkom123. en Welkom124.: precies wat in elke woordenlijst staat. Het Nationaal Cyber Security Centrum en het Amerikaanse instituut voor standaarden raden daarom iets anders aan:

  • Lengte boven rare tekens. Een wachtzin van een paar woorden, zoals zonnebloem fiets regen zolder, is sterker en makkelijker te onthouden. Laat lange wachtwoorden en spaties dus toe. Elk tekstveld krijgt een max_length uit Grenzen in Form, maar geef het wachtwoordveld een ruime grens, zoals 200 tekens, en haal er geen spaties af met strip(): een spatie hoort bij het wachtwoord.
  • Niet verplicht vervangen, alleen als er reden voor is, zoals een lek.

Inloggen beperken​

Een aanvaller zonder database kan nog steeds proberen in te loggen, keer op keer, met een woordenlijst. Daarom heeft /inloggen uit les 11 een limiet van vijf pogingen per minuut. Houd die streng op elk endpoint dat een wachtwoord controleert, ook als je er later een bij bouwt.

Wat grote sites nog meer doen​

Dit hoef je voor je eigen project niet te bouwen. Klap open wat je wilt lezen.

Controleren tegen gelekte wachtwoorden

De dienst Have I Been Pwned houdt een lijst bij van honderden miljoenen wachtwoorden uit eerdere lekken. Een site kan bij het registreren nagaan of een nieuw wachtwoord daarin staat, zonder het wachtwoord zelf te versturen: hij stuurt alleen de eerste vijf tekens van een hash, en vergelijkt de rest zelf.

Een slot op het account

Een limiet per computer stopt één computer. Een aanvaller met veel computers probeert vanaf elke computer een paar wachtwoorden, en blijft overal onder de grens. Daarom tellen veel sites ook per account: na tien foute pogingen op Sara's naam gaat haar account een kwartier op slot, van welke computer de pogingen ook kwamen.

Dat heeft een keerzijde. Wie Sara dwars wil zitten, typt tien keer een fout wachtwoord met haar naam, en dan kan zij zelf niet meer in. Sites houden het slot daarom kort, of vragen na een paar foute pogingen om een puzzel die een mens kan oplossen en een script niet, in plaats van het account dicht te zetten.

Peper

Het zout uit les 5 staat naast de hash in de database. Sommige sites doen er nog een peper bij: een geheim dat voor alle wachtwoorden hetzelfde is, maar níét in de database staat, bijvoorbeeld in een instelling op de server. Lekt alleen de database, dan mist wie hem heeft dat stukje, en kan hij met de hashes niets beginnen.

Tweestapsverificatie

Hoe goed je een wachtwoord ook bewaart, de gebruiker kan het zelf lekken: hergebruikt, afgekeken of ingetypt op een nepsite. Daarom vragen veel sites na het wachtwoord nog iets tweeds, dat de gebruiker heeft: een code uit een app op zijn telefoon, of een beveiligingssleutel. Dat heet tweestapsverificatie. Een gestolen wachtwoord alleen is dan niet genoeg.

Wachtwoord vergeten

Een site die je je wachtwoord terugmailt, bewaart het als gewone tekst: met Argon2 kun je dat niet eens, want je hebt het wachtwoord niet. Een goede site stuurt een link met een eenmalige, geheime code die na een korte tijd verloopt. Via die link kies je een nieuw wachtwoord. Zie je ooit je eigen wachtwoord in een mail terug, dan weet je hoe die site het bewaart.

Het wiel niet zelf uitvinden

Inloggen, tweestapsverificatie en wachtwoord vergeten: het is veel werk, en elk foutje is een gat. Grote sites gebruiken daarom vaak een bestaande oplossing, een bibliotheek die inloggen voor ze regelt, of een dienst waarmee je inlogt met een account dat je al hebt, zoals bij "Inloggen met Google". Zelf bouwen is goed om te leren hoe het werkt. Voor een echte site met echte gebruikers is een beproefde oplossing meestal de betere keus.

De wet​

Een wachtwoord hoort bij een persoon, dus in Europa valt het onder de AVG, de privacywet. Die eist dat je persoonsgegevens passend beveiligt, en wachtwoorden als gewone tekst bewaren is dat niet. Lekt er toch iets, dan is dat een datalek. Dat moet de organisatie binnen 72 uur melden bij de Autoriteit Persoonsgegevens, en als het een groot risico is ook bij de mensen van wie de gegevens zijn gelekt.

Andermans wachtwoorden achterhalen of gebruiken is bovendien strafbaar, ook als je "alleen even kijkt". Daarom maakte je in les 1 je eigen accounts, en keek je daarna alleen in je eigen database.

Opdracht: welke maatregel helpt waartegen?​

Kies bij elke situatie de maatregel uit deze reeks die het meest helpt. Voor situatie 2 en 4 heb je de blokken Controleren tegen gelekte wachtwoorden en Tweestapsverificatie hierboven nodig: klap ze open.

  1. Iemand probeert met een script duizend wachtwoorden per minuut uit op je inlogpagina.
  2. Sara gebruikt voor jouw site hetzelfde wachtwoord als voor een game die vorig jaar is gelekt.
  3. Je site bestaat al zes jaar, en de oudste hashes zijn gemaakt met lichtere instellingen dan nu.
  4. Iemand heeft het wachtwoord van Noor afgekeken, en probeert in te loggen.
Tip

Vraag je bij elke situatie af: gaat het om de database, om het inloggen, om het wachtwoord zelf, of om wie er inlogt?

Antwoord
  1. Een verzoeklimiet op /inloggen, zoals in les 11. Las je het blok over een slot op het account, dan kan dat er ook bij: een kort slot na veel foute pogingen.
  2. Controleren tegen gelekte wachtwoorden bij het registreren, zodat Sara een ander wachtwoord moet kiezen.
  3. check_needs_rehash bij het inloggen, uit les 10, zodat oude hashes vanzelf worden bijgewerkt.
  4. Tweestapsverificatie: het wachtwoord alleen is dan niet genoeg.

Dit was de laatste reeks. Door naar Beveilig je eigen project.