--- title: "Best practices voor Verify" description: "Hoe je de lengte en levensduur van een verificatiecode instelt, welk kanaal je waarvoor gebruikt, en waar de standaardinstellingen van Bird al voldoen aan NIST SP 800-63B en waar een instelling je erbuiten kan brengen." canonical: "https://bird.com/nl-nl/documentatie/guides/verify/best-practices" --- # Best practices voor Verify Verify wordt geleverd met standaardinstellingen die voor de meeste verificatiecodeflows geschikt zijn. Deze gids behandelt de keuzes die de standaardinstellingen niet voor je maken: hoe lang een code geldig moet zijn, hoeveel cijfers hij nodig heeft, welk kanaal past bij wat je daadwerkelijk verifieert, en hoe je een bezorgprobleem onderscheidt van een verificatieprobleem. Waar een publieke standaard een standpunt heeft, citeert deze gids dat. De standaard voor verificatiecodeauthenticatie is NIST SP 800-63B, [Digital Identity Guidelines: Authentication and Authenticator Management](https://pages.nist.gov/800-63-4/sp800-63b.html), opgehaald op 3 september 2026. Citaten komen uit de huidige revisie. De oudere Revision 3 waar veel OTP-advies nog naar verwijst, draagt de eigen banner van NIST: vervangen door SP 800-63-4 per 1 augustus 2025. ## Houd de code op zes cijfers of meer De codes van Bird staan standaard op 6 cijfers en `options.code_length` accepteert 4 tot 8 per verzoek ([Verificatie-instellingen](/docs/guides/verify/sending-verifications#verification-settings)). De standaard is de juiste keuze en het lage uiteinde van dat bereik niet: > The verifier SHALL generate random authentication secrets that are at least six decimal digits (or equivalent) in length using an approved random bit generator Een code van 4 of 5 cijfers valt binnen wat de API accepteert en buiten wat de standaard toestaat. Verkort een code alleen voor een flow waarin je hebt besloten dat de entropie van de verificatiecode niet het beveiligingswerk doet. ## Houd de levensduur op tien minuten of minder **Duration** staat standaard op 10 minuten en accepteert 1 tot 999 ([Verificatie-instellingen](/docs/guides/verify/sending-verifications#verification-settings)). De standaard zit precies op het plafond van de standaard: > In all cases, the authentication SHALL be considered invalid unless completed within 10 minutes. Het bereik loopt dus ver voorbij de limiet. Duration verhogen om het aantal supportmeldingen over verlopen codes te verminderen is de ene instellingswijziging die een flow stilletjes buiten 800-63B brengt. Als codes verlopen voordat gebruikers ze bereiken, zit de oplossing meestal in het verzendpad en niet in het tijdvenster. ## Verwacht twee lagen van beperking van het aantal verzoeken Een controleverzoek wordt op twee niveaus begrensd, en de twee limieten beantwoorden verschillende dreigingen. **Je instelling.** **Maximum Retries** staat standaard op 5 en accepteert 1 tot 10; daarna faalt de verificatie met `attempts_exhausted`. De standaard vereist dat deze grens bestaat voor een code die zo kort is, en voegt een regel toe die de moeite waard is: > Generating a new authentication secret SHALL NOT reset the failed authentication count. De grens heeft een plafond, en dit is de enige plek waar elke waarde die Verify biedt comfortabel binnen de standaard valt: > the verifier SHALL limit consecutive failed authentication attempts using a specific authenticator on a single subscriber account to no more than 100 by disabling that authenticator Maximum Retries gaat tot maximaal 10, dus geen enkele configuratie die je kunt kiezen bereikt 100. Dat is het spiegelbeeld van de twee secties hierboven: codelengte en levensduur hebben elk een ondersteunde waarde die 800-63B verlaat, en de pogingslimiet niet. **De platformlimieten van Bird**, die gelden ongeacht je configuratie: 5 verzendingen per adres per rollend uur voor starten en opnieuw verzenden, en 10 controles per set ontvangeradressen per minuut. Beide retourneren `429` met een `Retry-After`-header ([Misbruikbeveiliging](/docs/guides/verify/sending-verifications#abuse-guardrails)). Deze bestaan om te voorkomen dat OTP-verkeer als wapen wordt ingezet tegen je portemonnee of de telefoon van een vreemde, dus beschouw een `429` hier als het systeem dat werkt en niet als een limiet om omheen te bouwen. ## Kies het kanaal op basis van wat je verifieert Verify bezorgt via e-mail, SMS, WhatsApp en Telegram ([Kanalen](/docs/guides/verify/overview#channels)). De standaard behandelt twee daarvan heel verschillend, en het onderscheid gaat over waarvoor de code _dient_ en niet over welk kanaal hem draagt. **E-mail is geen authenticatiefactor.** 800-63B is ondubbelzinnig: > Email SHALL NOT be used for out-of-band authentication because it may be vulnerable to: > > - Access using only a password > - Interception in transit or at intermediate mail servers > - Rerouting attacks, such as those caused by Domain Name System (DNS) spoofing Dezelfde passage maakt een uitzondering voor het geval waarvoor het e-mailkanaal van Verify is gebouwd: > Confirmation codes that are sent to validate email addresses or are issued as recovery codes (see Sec. 4.2.1.2) are not authentication processes and not affected by the above prohibition. Een e-mailcode die bewijst dat iemand een adres beheert valt dus binnen de uitzondering van de standaard en is in orde. Een e-mailcode die als tweede factor bij inloggen wordt gebruikt niet. Als je flow die tweede is, gebruik dan niet het e-mailkanaal. **SMS en spraak zijn toegestaan maar beperkt.** Bezorging via het telefoonnetwerk brengt drie plichten met zich mee, in twee opeenvolgende zinnen: > Accordingly, verifiers SHALL ensure that alternative authenticator types are available to all subscribers and SHOULD remind subscribers of this limitation of PSTN out-of-band authenticators before binding one or more devices controlled by the subscriber. Verifiers SHOULD consider risk indicators (e.g., device swap, SIM change, number porting, other abnormal behavior) before using the PSTN to deliver an out-of-band authentication secret. De `SHALL` is een productvereiste en geen Verify-instelling: als SMS je enige factor is, voldoe je er niet aan. De kanaalvolgorde per land van Verify helpt bij bezorging, omdat WhatsApp in de meeste landen eerst wordt geprobeerd met SMS als terugval ([Kanalen](/docs/guides/verify/overview#channels)), maar SMS, WhatsApp en Telegram zijn allemaal bezorgpaden voor één authenticatortype, out-of-band, dus wisselen tussen die kanalen is geen alternatief type aanbieden. De twee `SHOULD`s zijn degene die een productteam implementeert: een melding op het moment dat een gebruiker een telefoonnummer koppelt, en een controle van porterings- en SIM-wijzigingssignalen voordat je naar dat nummer verstuurt. ## Lees een fout voordat je opnieuw verstuurt Een code die niet aankomt en een code die aankomt maar verkeerd wordt getypt vereisen een andere aanpak, en de events onderscheiden ze ([Events](/docs/guides/verify/events)). `verify.attempt.undelivered` bevat een `reason`, en wat er daarna gebeurt hangt af van het kanaalplan van de ontvanger. Bij een ontvanger met meer dan één beschikbaar kanaal beëindigt het de verificatie niet: Bird gaat door naar het volgende kanaal, dat zijn eigen `verify.attempt.sent` krijgt, dus een enkele niet-bezorgde poging is geen dode verificatie en vereist geen opnieuw verzenden van jouw kant. Bij een ontvanger met één kanaal is er niets om naar door te gaan, en de verificatie eindigt. Dat einde vereist eigen afhandeling, en één event identificeert het. De `failed`-status wordt gedeeld: een verificatie komt daar terecht zowel wanneer te veel onjuiste verificatiecodes zijn ingediend, met `reason` `attempts_exhausted`, als wanneer geen gepland kanaal er een kon bezorgen, met `reason` `undeliverable`. Alleen het tweede geval genereert `verify.verification.failed`. Dus bij een ontvanger met één kanaal is het dat event en niet de status dat je vertelt dat niemand een code heeft ontvangen. Eén eigenschap om op te ontwerpen in plaats van te ontdekken, en deze is van Bird zelf en niet van de standaard: [Events](/docs/guides/verify/events) vermeldt dat bezorgrapporten indicatief zijn en niet gegarandeerd, omdat carriers en mailboxproviders variëren in wat ze bevestigen en hoe snel. In sommige markten komt een pogingevent minuten te laat aan of maakt het geen onderscheid tussen bezorging en acceptatie. Bouw het "I didn't get a code"-pad op [`POST /v1/verify/verifications/next-channel`](/docs/guides/verify/sending-verifications#send-the-code-on-another-channel), dat de verificatie voortzet, in plaats van te wachten op een bezorgevent dat mogelijk niet komt. ## Herhaal het verzoek, niet de verificatie Alle drie Verify-endpoints accepteren `Idempotency-Key` ([Veilig opnieuw proberen](/docs/guides/verify/sending-verifications#retrying-safely)). Na een timeout of een verbroken verbinding herhaalt opnieuw proberen met dezelfde sleutel het oorspronkelijke antwoord: er wordt geen tweede code verstuurd en er wordt geen controlepoging verbruikt. Zonder sleutel stuurt opnieuw proberen na een verloren antwoord een nieuwe code en verbruikt een extra verzending van het uurlimiet. ## Weet wat een verzending kost Facturering wordt gekoppeld aan elke verzonden code, tegen het kanaaltarief voor de bestemming, en een opnieuw verzenden of terugval voegt kosten per verzending toe ([Kosten en facturering](/docs/guides/verify/sending-verifications#cost-and-billing)). Twee gevolgen bepalen een retry-beleid: - Een verificatie die door meerdere kanalen valt kost meerdere verzendingen, dus een breed kanaalplan is net zozeer een kostenbeslissing als een bezorgbeslissing. - Telegram factureert op een ander moment. Telegram wordt gevraagd of het nummer een bericht kan ontvangen, en de kosten worden in rekening gebracht wanneer het antwoord ja is, tegen een vast tarief wereldwijd. Een nummer dat niet bereikbaar is, is gratis en gaat door naar het volgende kanaal zonder dat er iets wordt gefactureerd. Een verrekening betekent dus geaccepteerd voor bezorging en niet aangekomen: een code die vervolgens niet wordt bezorgd blijft in rekening gebracht, en de verificatie betaalt opnieuw voor het kanaal waarnaar wordt teruggevallen. Waar die tweede verrekening ongewenst is, verwijder je Telegram uit de kanaalvolgorde voor die landen op de pagina Countries ([Kosten en facturering](/docs/guides/verify/sending-verifications#cost-and-billing)). ## Volgende stappen - [Verificaties verzenden](/docs/guides/verify/sending-verifications): de instellingen, de beveiligingen en de volledige statuslijst - [Events](/docs/guides/verify/events): elk sessie- en bezorgevent met zijn payload - [Countries](/docs/guides/verify/countries): kanaalvolgorde en beschikbaarheid per land - [Afzenders en branding](/docs/guides/verify/senders): hoe elk bericht eruitziet ## Related resources - [Verify phone numbers at signup](/learn/series/verify-phone-numbers-at-signup) (video) - [What does OTP mean? One-time passwords explained](/explained/verify/what-does-otp-mean) (answer) - [Customer verification](/verify-api) (product) - [Build your first integration](/learn/paths/integration) (course) [Get an implementation brief](/learn/workspace?topic=verify)