--- title: "Praktik terbaik Verify" description: "Cara mengatur panjang dan masa berlaku kode verifikasi, kanal mana yang digunakan untuk apa, dan di mana default Bird sudah memenuhi NIST SP 800-63B serta di mana suatu pengaturan dapat membawa Anda keluar dari standar tersebut." canonical: "https://bird.com/id-id/dokumentasi/guides/verify/best-practices" --- # Praktik terbaik Verify Verify dilengkapi default yang cocok untuk sebagian besar alur kode verifikasi sekali pakai. Panduan ini membahas keputusan yang tidak ditentukan oleh default: berapa lama kode harus berlaku, berapa digit yang diperlukan, kanal mana yang sesuai untuk apa yang sebenarnya Anda verifikasi, dan cara membedakan masalah pengiriman dari masalah verifikasi. Jika suatu standar publik memiliki pandangan, panduan ini mengutipnya. Standar untuk autentikasi kode verifikasi adalah NIST SP 800-63B, [Digital Identity Guidelines: Authentication and Authenticator Management](https://pages.nist.gov/800-63-4/sp800-63b.html), diakses 3 September 2026. Kutipan diambil dari revisi terkini. Revision 3 yang lebih lama dan masih banyak dikutip dalam saran OTP memuat banner NIST sendiri: digantikan oleh SP 800-63-4 per 1 Agustus 2025. ## Gunakan kode enam digit atau lebih Kode Bird default-nya 6 digit dan `options.code_length` menerima 4 hingga 8 per permintaan ([Pengaturan verifikasi](/docs/guides/verify/sending-verifications#verification-settings)). Default tersebut adalah pilihan yang tepat, dan batas bawah rentang itu bukan: > The verifier SHALL generate random authentication secrets that are at least six decimal digits (or equivalent) in length using an approved random bit generator Kode 4 atau 5 digit berada di dalam rentang yang diterima API tetapi di luar yang diizinkan standar. Perpendek kode hanya untuk alur di mana Anda sudah memutuskan bahwa entropi kode verifikasi bukan yang menjalankan fungsi keamanan. ## Batasi masa berlaku pada sepuluh menit atau kurang **Duration** default-nya 10 menit dan menerima 1 hingga 999 ([Pengaturan verifikasi](/docs/guides/verify/sending-verifications#verification-settings)). Default ini tepat berada di batas atas standar: > In all cases, the authentication SHALL be considered invalid unless completed within 10 minutes. Jadi rentang yang tersedia jauh melampaui batas standar. Menaikkan Duration untuk mengurangi kontak dukungan tentang kode kedaluwarsa adalah satu-satunya perubahan pengaturan yang diam-diam membawa alur keluar dari 800-63B. Jika kode kedaluwarsa sebelum pengguna sempat membacanya, perbaikan biasanya ada di jalur pengiriman, bukan di jendela waktunya. ## Siapkan dua lapisan pembatasan laju permintaan Upaya pengecekan dibatasi dua kali, dan kedua batas tersebut menjawab ancaman yang berbeda. **Pengaturan Anda.** **Maximum Retries** default-nya 5 dan menerima 1 hingga 10; melewati batas itu, verifikasi gagal dengan `attempts_exhausted`. Standar mewajibkan batas ini ada untuk kode sependek ini, dan menambahkan aturan yang perlu diketahui: > Generating a new authentication secret SHALL NOT reset the failed authentication count. Batas tersebut memiliki plafon, dan ini satu-satunya tempat di mana setiap nilai yang ditawarkan Verify berada dengan nyaman di dalam standar: > 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 maksimal 10, jadi tidak ada konfigurasi yang bisa Anda pilih yang mencapai 100. Ini kebalikan dari dua bagian di atas: panjang kode dan durasi masing-masing memiliki nilai yang didukung tetapi keluar dari 800-63B, sedangkan batas upaya tidak. **Batas platform Bird**, yang berlaku apa pun konfigurasi Anda: 5 pengiriman per alamat per jam bergulir untuk pembuatan dan pengiriman ulang, dan 10 pengecekan per set alamat penerima per menit. Keduanya mengembalikan `429` dengan header `Retry-After` ([Perlindungan penyalahgunaan](/docs/guides/verify/sending-verifications#abuse-guardrails)). Batas ini ada untuk mencegah lalu lintas OTP dijadikan senjata terhadap anggaran Anda atau perangkat orang lain, jadi perlakukan `429` di sini sebagai sistem yang bekerja sebagaimana mestinya, bukan sebagai batas yang perlu disiasati. ## Pilih kanal sesuai yang Anda verifikasi Verify mengirim melalui email, SMS, WhatsApp, dan Telegram ([Kanal](/docs/guides/verify/overview#channels)). Standar memperlakukan dua di antaranya secara sangat berbeda, dan perbedaannya terletak pada _tujuan_ kode, bukan kanal yang membawanya. **Email bukan faktor autentikasi.** 800-63B bersifat kategoris: > 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 Bagian yang sama mengecualikan kasus yang memang dirancang untuk kanal email Verify: > 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. Jadi kode email yang membuktikan seseorang menguasai suatu alamat berada dalam cakupan pengecualian standar dan sah. Kode email yang digunakan sebagai faktor kedua saat masuk tidak sah. Jika alur Anda yang kedua, jangan gunakan kanal email. **SMS dan voice diizinkan tetapi dibatasi.** Pengiriman melalui jaringan telepon membawa tiga kewajiban, dalam dua kalimat berurutan: > 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. `SHALL` adalah persyaratan produk, bukan pengaturan Verify: jika SMS adalah satu-satunya faktor Anda, Anda tidak memenuhinya. Urutan kanal per negara Verify membantu pengiriman, karena WhatsApp dicoba lebih dulu di sebagian besar negara dengan SMS sebagai cadangan ([Kanal](/docs/guides/verify/overview#channels)), tetapi SMS, WhatsApp, dan Telegram semuanya adalah jalur pengiriman untuk satu tipe autentikator, out-of-band, sehingga berpindah di antaranya bukan berarti menawarkan tipe alternatif. Dua `SHOULD` yang tersisa adalah yang diimplementasikan oleh tim produk: catatan di titik pengguna mengikat nomor telepon, dan pemeriksaan sinyal porting dan pergantian SIM sebelum mengirim ke nomor tersebut. ## Baca kegagalan sebelum Anda mengirim ulang Kode yang tidak sampai dan kode yang sampai tetapi salah ketik memerlukan penanganan berbeda, dan event membedakan keduanya ([Event](/docs/guides/verify/events)). `verify.attempt.undelivered` membawa `reason`, dan apa yang terjadi selanjutnya bergantung pada rencana kanal penerima. Pada penerima dengan lebih dari satu kanal tersedia, ini tidak mengakhiri verifikasi: Bird melanjutkan ke kanal berikutnya, yang mendapat `verify.attempt.sent` sendiri, sehingga satu upaya yang tidak terkirim bukan verifikasi mati dan tidak memerlukan pengiriman ulang dari Anda. Pada penerima dengan satu kanal, tidak ada kanal lanjutan, dan verifikasi berakhir. Akhir tersebut memerlukan penanganan tersendiri, dan satu event mengidentifikasinya. Status `failed` bersifat bersama: verifikasi masuk ke sana baik ketika terlalu banyak kode verifikasi salah dikirimkan, dengan `reason` `attempts_exhausted`, maupun ketika tidak ada kanal yang direncanakan berhasil mengirimkan, dengan `reason` `undeliverable`. Hanya yang kedua yang memancarkan `verify.verification.failed`. Jadi pada penerima dengan satu kanal, event itulah, bukan statusnya, yang memberi tahu Anda bahwa tidak ada yang menerima kode. Satu properti yang perlu dirancang sejak awal, dan ini milik Bird sendiri, bukan dari standar: [Event](/docs/guides/verify/events) menyatakan bahwa laporan pengiriman bersifat indikatif, bukan dijamin, karena operator dan penyedia kotak masuk berbeda-beda dalam apa yang mereka konfirmasi dan seberapa cepat. Di beberapa pasar, event upaya tiba terlambat beberapa menit atau tidak membedakan pengiriman dari penerimaan. Bangun jalur "I didn't get a code" berdasarkan [`POST /v1/verify/verifications/next-channel`](/docs/guides/verify/sending-verifications#send-the-code-on-another-channel), yang melanjutkan verifikasi, bukan berdasarkan menunggu event pengiriman yang mungkin tidak datang. ## Coba lagi permintaannya, bukan verifikasinya Ketiga endpoint Verify menerima `Idempotency-Key` ([Mencoba lagi dengan aman](/docs/guides/verify/sending-verifications#retrying-safely)). Setelah timeout atau koneksi terputus, mencoba lagi dengan kunci yang sama memutar ulang respons asli: tidak ada kode kedua yang terkirim dan tidak ada upaya pengecekan yang terpakai. Tanpa kunci, percobaan ulang setelah respons hilang mengirim kode lain dan menghabiskan satu pengiriman dari batas per jam. ## Ketahui biaya setiap pengiriman Tagihan melekat pada setiap kode yang dikirim, sesuai tarif kanal untuk tujuan tersebut, dan pengiriman ulang atau fallback menambah biaya per pengiriman ([Biaya dan penagihan](/docs/guides/verify/sending-verifications#cost-and-billing)). Dua konsekuensi membentuk kebijakan percobaan ulang: - Verifikasi yang melewati beberapa kanal menimbulkan biaya beberapa pengiriman, sehingga rencana kanal yang luas adalah keputusan biaya sekaligus keputusan pengiriman. - Telegram menagih di titik yang berbeda. Telegram ditanyai apakah nomor tersebut dapat menerima pesan, dan biaya melekat ketika jawabannya ya, dengan tarif tetap di seluruh dunia. Nomor yang tidak dapat dijangkau tidak dikenai biaya dan lanjut ke kanal berikutnya tanpa tagihan. Jadi biaya berarti diterima untuk pengiriman, bukan sudah sampai: kode yang kemudian tidak terkirim tetap dikenai biaya, dan verifikasi membayar lagi untuk kanal yang menjadi tujuan fallback. Jika biaya kedua itu tidak diinginkan, keluarkan Telegram dari urutan kanal untuk negara-negara tersebut di halaman Countries ([Biaya dan penagihan](/docs/guides/verify/sending-verifications#cost-and-billing)). ## Langkah selanjutnya - [Mengirim verifikasi](/docs/guides/verify/sending-verifications): pengaturan, perlindungan, dan daftar status lengkap - [Event](/docs/guides/verify/events): setiap event sesi dan pengiriman beserta payload-nya - [Countries](/docs/guides/verify/countries): urutan dan ketersediaan kanal per negara - [Pengirim dan branding](/docs/guides/verify/senders): tampilan setiap pesan ## 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)