Wat is tweestapsverificatie? Een heldere gids

Tweestapsverificatie (2FA) is een manier van inloggen waarbij je twee verschillende soorten bewijs moet leveren dat je bent wie je zegt te zijn: meestal iets wat je weet, zoals een wachtwoord, plus iets wat je hebt, zoals je telefoon of een beveiligingssleutel. Als een crimineel je wachtwoord steelt of raadt, komt die nog steeds niet binnen zonder de tweede factor. Het is een van de eenvoudigste manieren om accounts die ertoe doen te beschermen.

Waarom het ertoe doet als je met AI bouwt

Als je een AI-builder vraagt om "inloggen", krijg je meestal e-mail en wachtwoord. Dat is een goed begin, maar wachtwoorden worden hergebruikt, gephisht en gelekt. Als je app iets waardevols bevat (klantgegevens, facturen, beheerfuncties, betalingsinstellingen), kan één gestolen wachtwoord alles blootleggen.

2FA raakt ook beslissingen waar je misschien niet meteen aan denkt:

• Wie het moet gebruiken. Optioneel voor iedereen, verplicht voor beheerders, of verplicht voor allen?
• Welke methoden je ondersteunt. Codes uit een app, sms-berichten, passkeys, beveiligingssleutels.
• Wat er gebeurt als iemand buiten de deur staat. Verloren telefoons zijn het meest voorkomende supportverzoek bij elke app met 2FA.
• Waar het wordt afgedwongen. De controle moet op de server gebeuren. Een 2FA-scherm dat alleen in de browser de pagina verbergt, kan worden omzeild.

Je hoeft de cryptografie zelf niet te bouwen; goed geteste bibliotheken en authenticatieproviders regelen dat. Maar je moet wel weten wat je moet vragen.

Een alledaagse vergelijking

Denk aan een kluisje bij de bank. Om het te openen heb je je identiteitsbewijs nodig (iets wat de bank controleert dat je bent of weet) en de fysieke sleutel (iets wat je hebt). Een dief die je handtekening namaakt, heeft de sleutel nog steeds niet. Een dief die de sleutel uit je zak haalt, komt de identiteitscontrole nog steeds niet door.

2FA werkt op dezelfde manier. Het wachtwoord is de handtekening; de telefoon of beveiligingssleutel is de fysieke sleutel. Elk van beide is alleen niet genoeg.

De drie soorten factoren

Beveiligingsstandaarden, zoals de richtlijnen voor digitale identiteit van het Amerikaanse National Institute of Standards and Technology (NIST), groeperen factoren in drie soorten:

Het kernwoord is verschillend. Een wachtwoord plus een geheime vraag zijn twee dingen die je weet, dus het is geen echte tweestapsverificatie. Als één lek beide kan onthullen, telt het maar als één.

De gangbare 2FA-methoden vergeleken

De richtlijnen van NIST behandelen methoden waarbij je een code typt (sms, e-mail, authenticator-apps) als niet bestand tegen phishing, en markeren het verzenden van codes via het telefoonnetwerk als "beperkt". Passkeys en hardware-beveiligingssleutels, gebaseerd op de WebAuthn/FIDO2-standaarden, zijn de methoden die NIST als bestand tegen phishing beschouwt.

De praktische conclusie: een authenticator-app is een sterke, eenvoudige standaard voor de meeste apps, en passkeys zijn het waard om aan te bieden als je gebruikers er gemakkelijk mee overweg kunnen.

Een uitgewerkt voorbeeld: 2FA voor een klantenportaal

Stel dat je een portaal hebt gebouwd waar een klein accountantskantoor belastingdocumenten met klanten deelt. Zo werkt een verstandige 2FA-opzet, stap voor stap.

Inschakelen (registratie). Priya, een klant, opent Instellingen en klikt op "Tweestapsverificatie inschakelen". De app genereert een geheim en toont het als QR-code. Zij scant die met haar authenticator-app, die dan zescijferige codes gaat tonen. Ze typt de huidige code in het portaal om te bewijzen dat de instelling werkt. De app toont tien herstelcodes en vraagt haar die ergens veilig op te slaan.

Daarna inloggen.

1. Priya voert haar e-mail en wachtwoord in. De server controleert die.
2. In plaats van haar meteen in te loggen, markeert de server de sessie als "wachtwoord goed, tweede factor nog open" en toont het codescherm.
3. Ze typt de code uit haar app. De server controleert die tegen haar opgeslagen geheim, met een kleine marge voor klokafwijking.
4. Pas dan maakt de server een volledige sessie aan en kan ze de documenten zien.

Wat een aanvaller ziet. Als Priya's wachtwoord van een andere site is gelekt, loopt de aanvaller vast bij stap 3. Elke mislukte codepoging wordt geteld, en na meerdere foute pogingen wordt het account tijdelijk vergrendeld en krijgt Priya een e-mail.

Haar telefoon kwijt. Priya gebruikt een van haar herstelcodes om in te loggen, zet 2FA uit en weer aan met haar nieuwe telefoon, en krijgt nieuwe herstelcodes. Een gebruikte code kan nooit meer worden gebruikt.

Voor medewerkers. De accountants van het kantoor kunnen de bestanden van elke klant zien, dus het portaal vereist 2FA voor medewerkersaccounts; ze komen pas in het dashboard als ze zijn geregistreerd.

Veelgebruikte termen uitgelegd

Veelgemaakte fouten en misverstanden

• "2FA maakt een account onhackbaar." Het maakt het veel moeilijker. Nepsites voor phishing kunnen ingetypte codes nog steeds in realtime onderscheppen; daarom bestaan passkeys.
• De code alleen in de browser controleren. Als de server na het wachtwoord een volledige sessie uitgeeft, is het codescherm slechts decoratie. De server moet de toegang weigeren tot de tweede factor is geslaagd.
• Geen limiet op codepogingen. Een code van zes cijfers heeft een miljoen mogelijkheden. Zonder rate limiting en vergrendelingen kan een aanvaller gewoon blijven raden.
• Herstel vergeten. Zonder herstelcodes wordt elke verloren telefoon een supportticket, of een klant die buiten de deur staat.
• Het TOTP-geheim onzorgvuldig opslaan. Het gedeelde geheim moet versleuteld in de database staan en na de instelling nooit meer worden getoond.
• Gebruikers 2FA laten uitzetten zonder opnieuw te controleren. Het uitschakelen van 2FA of het wijzigen van het e-mailadres moet om het wachtwoord en een actuele code vragen.
• Een wachtwoord plus een geheime vraag telt als 2FA. Dat is niet zo; beide zijn dingen die je weet.

Wat je aan je AI-builder kunt vragen

• "Voeg optionele tweestapsverificatie toe met een authenticator-app (TOTP), met een QR-code voor de instelling en een bevestigingscode voordat het wordt ingeschakeld."
• "Toon tien eenmalige herstelcodes wanneer 2FA is ingeschakeld. Sla ze gehasht op, zoals wachtwoorden."
• "Dwing 2FA af op de server: geen volledige sessie totdat de tweede factor is geslaagd."
• "Beperk het aantal codepogingen en vergrendel de login 15 minuten na herhaalde fouten. Stuur de gebruiker in dat geval een e-mail."
• "Verplicht 2FA voor beheerdersaccounts."
• "Vraag om het wachtwoord en een actuele code voordat 2FA wordt uitgeschakeld of het accounte-mailadres wordt gewijzigd."
• "Gebruik een bekende bibliotheek of de ingebouwde 2FA van onze authenticatieprovider; schrijf de cryptografie niet zelf."
• "Leg uit welke methode je hebt gebruikt en waar de geheimen worden opgeslagen."

Als je een gehoste authenticatieprovider gebruikt, controleer dan of die al 2FA of passkeys aanbiedt; een ingebouwde functie aanzetten is meestal veiliger dan eigen code. De stap-voor-stap-versie staat in hoe je tweestapsverificatie toevoegt, en wat authenticatie is behandelt de basis van inloggen eronder.

Tweestapsverificatie in Mythex

Mythex bevat geen ingebouwd inlogsysteem voor de gebruikers van je app, dus 2FA maakt deel uit van de authenticatiemethode die je kiest: je eigen e-mail-en-wachtwoordlogin met de database van het project als basis, of een gehoste provider die 2FA aanbiedt. Je vraagt de agent in de chat om het toe te voegen, en eventuele providersleutels gaan in de projectgeheimen en niet in de chat zelf. Het recept in de documentatie over inloggen aan je app toevoegen bevat een startprompt om aan te passen, en beveiliging voor apps die je bouwt behandelt de gewoonten rond sleutels. Loop vóór de lancering de beveiligingschecklist voor met AI gebouwde apps door.

Veelgestelde vragen