दुरुपयोग-रोधी और कोड सुरक्षा
प्रीव्यू मेंकोड एक रहस्य है। हम इसे वैसा ही मानते हैं।
A one-time code is only as good as the way it's generated, stored, and rate-limited. Bird Verify generates codes with a cryptographic source, stores only a hash, compares in constant time, and caps both sends and guesses, so a leaked log or a brute-force loop gets an attacker nowhere. Fraud scoring builds on this base next.
import { BirdClient } from "@messagebird/sdk";
const bird = new BirdClient({ apiKey: process.env.BIRD_API_KEY! });
// Send the code, then check it by recipient.
await bird.verify.verifications.create({
to: { phone_number: "+15551234567" },
}).safe();
const { data } = await bird.verify.verifications.check({
to: { phone_number: "+15551234567" },
code: userInput,
}).safe();
सुरक्षा जो डिफ़ॉल्ट रूप से चालू है, कोई ऐड-ऑन नहीं।
Every verification on the Bird Verify API carries the same protections: the code is generated server-side, never returned, and stored only as a hash; checks run in constant time and against a bounded attempt budget; and sends are capped per recipient and per workspace. You don't opt in or wire these up: they're how the API behaves, whether you run it as two-factor login or passwordless sign-in.
हर वेरिफ़िकेशन पर पाँच सुरक्षाएँ।
कोई सेटअप स्टेप नहीं, कोई ऐड-ऑन SKU नहीं।
- 01
क्रिप्टोग्राफिक जेनरेशन।
कोड एक क्रिप्टोग्राफिक रैंडम स्रोत से लिए जाते हैं, कोड स्पेस में समान रूप से वितरित, न कि किसी पूर्वानुमानित काउंटर या टाइमस्टैम्प से।
- 02
आराम की स्थिति में hash, वायर पर कभी बाहर नहीं।
प्रत्येक कोड का केवल एक HMAC-SHA256 स्टोर होता है; plaintext कभी API द्वारा लौटाया नहीं जाता और न ही आपके स्टैक या हमारे logs में लिखा जाता है।
- 03
कॉन्स्टेंट-टाइम तुलना।
सबमिट किए गए कोड की तुलना कॉन्स्टेंट टाइम में होती है, इसलिए किसी हमलावर को इससे कुछ पता नहीं चलता कि जाँच में कितना समय लगा।
- 04
अटेम्प्ट लॉकआउट।
प्रत्येक सेशन में जाँच की एक सीमित संख्या होती है (डिफ़ॉल्ट रूप से 5)। एक बार ये खत्म होने पर सेशन विफल हो जाता है, इसलिए अनुमान लगाना हमेशा नहीं चल सकता।
- 05
सेंड कैप।
एक प्रति-प्राप्तकर्ता सेंड कैप और एक रीसेंड कूलडाउन खर्च और दुरुपयोग की सतह को सीमित करते हैं, हर एक Retry-After के साथ 429।
अनुमान आपके उपयोगकर्ताओं से पहले खत्म हो जाते हैं।
गलत कोड एक परिणाम के रूप में शेष अटेम्प्ट के साथ वापस आता है, और बजट खत्म होते ही सेशन विफल हो जाता है, इसलिए ब्रूट-फोर्स लूप एक खुले दरवाजे के बजाय एक दीवार से टकराता है।
const { data } = await bird.verify.verifications.check({
to: { phone_number: "+15551234567" },
code: guess,
}).safe();
// wrong code, attempts left → { result: "invalid", attempts_remaining: 2 }
// budget spent, session done → { result: "failed", attempts_remaining: null }आगे आने वाला: fraud सिग्नल और SMS-पंपिंग सुरक्षा।
The per-send history Verify records today is the groundwork for a fraud layer we're building now. It rides the same create and check calls, so adopting it later is a config change, not a re-integration.
Risk signals on create. Pass device, IP, and request context on a verification, and high-risk attempts get a blocked outcome before a code is ever sent, so you're not paying to message an attacker.
SMS-पंपिंग और AIT सुरक्षा। प्रति-देश और प्रति-prefix सेंड कैप साथ ही प्रति-workspace खर्च सीमा उस artificially-inflated-traffic हमले को रोकती है जो carrier राजस्व हिस्सेदारी के लिए OTP को प्रीमियम नंबर रेंज तक पहुँचाता है।
Built on what's already there. Risk decisioning reads the attempt history Verify keeps from day one, and the blocked outcome is already part of the status model, so the fraud layer lands without reshaping your integration.
वेरिफ़िकेशन सुरक्षा FAQ
वन-टाइम कोड कहाँ स्टोर होता है?
आप किसी को कोड ब्रूट-फोर्स करने से कैसे रोकते हैं?
SMS पंपिंग और artificially inflated traffic के बारे में क्या?
क्या इन सुरक्षाओं की अतिरिक्त लागत लगती है?
मेरे उपयोगकर्ता किसकी ओर से कोड देखते हैं?
बाकी Verify प्लेटफ़ॉर्म
एक API, कीज़ का एक सेट। बाकी क्षमताओं को एक्सप्लोर करें।
कोड जिस तरह जेनरेट, स्टोर और रेट-लिमिट होने चाहिए, उसी तरह होते हैं।
सुरक्षा Bird Verify में बिल्ट-इन है, ऊपर से बेची नहीं जाती: चैनल, कोड और लिमिट वही दो endpoints हैं।