// ความปลอดภัย OTP

แนวปฏิบัติที่ดีในการติดตั้ง OTP: โค้ด การหมดอายุ การจำกัดอัตรา และการสำรอง

รหัสผ่านครั้งเดียวดูเหมือนเรื่องเล็ก — สร้างตัวเลข ส่งเป็นข้อความ ตรวจสอบมัน แต่รายละเอียดคือที่ที่บั๊กยึดบัญชีอาศัยอยู่ คู่มือนี้ครอบคลุมการตัดสินใจที่ทำให้โฟลว์ OTP ปลอดภัยและใช้งานได้จริง: ค่าเอนโทรปีของโค้ด การจัดเก็บ ช่วงเวลาหมดอายุ การจำกัดอัตรา การลองใหม่ และช่องทางสำรอง

สร้างโค้ดด้วยเอนโทรปีจริง

ใช้ตัวสร้างเลขสุ่มที่ปลอดภัยเชิงการเข้ารหัส อย่าใช้ซีดที่คาดเดาได้หรือค่าที่มาจากการประทับเวลา หกหลักเป็นสมดุลปกติของความปลอดภัยและการใช้งาน; โค้ดที่สั้นกว่าต้องการการจำกัดอัตราที่เข้มงวดกว่าเพื่อความปลอดภัย

อย่าส่งโค้ดเดียวกันสองครั้ง และอย่าทำให้โค้ดเดาได้จากรหัสผู้ใช้หรือลำดับ ความปลอดภัยทั้งหมดของ OTP ทาง SMS ขึ้นอยู่กับการที่โค้ดคาดเดาไม่ได้ภายในช่วงอายุสั้นของมัน

  • ใช้ CSPRNG (เช่น ไลบรารี secrets/crypto) ไม่ใช่ PRNG ทั่วไป
  • 6 หลักเป็นมาตรฐาน; ถ้าคุณใช้ 4 หลัก ให้เข้มการจำกัดอัตราและการหมดอายุให้สุด
  • หนึ่งโค้ดต่อหนึ่งคำขอ; ทำให้โค้ดก่อนหน้าใช้ไม่ได้เมื่อออกโค้ดใหม่

จัดเก็บโค้ดอย่างปลอดภัย อย่าเก็บเป็นข้อความธรรมดา

ปฏิบัติต่อ OTP เหมือนรหัสผ่านอายุสั้น จัดเก็บแฮชของโค้ด (พร้อมตัวระบุและการหมดอายุ) แทนค่าดิบ เพื่อให้การรั่วไหลของฐานข้อมูลไม่เปิดเผยโค้ดที่ยังใช้ได้ เปรียบเทียบด้วยฟังก์ชันเวลาคงที่เพื่อหลีกเลี่ยงการโจมตีเชิงเวลา และลบเรกคอร์ดทันทีที่ถูกใช้หรือหมดอายุ

  • แฮชโค้ดก่อนจัดเก็บ; เปรียบเทียบด้วยเวลาคงที่
  • ผูกแต่ละโค้ดกับผู้ใช้/เซสชันและวัตถุประสงค์เดียว
  • ลบเมื่อสำเร็จ หมดอายุ หรือหลังถึงเพดานจำนวนครั้งที่พยายาม

ตั้งช่วงเวลาหมดอายุที่สั้น

โค้ดควรมีอายุเป็นนาที ไม่ใช่ชั่วโมง การหมดอายุ 5–10 นาทีเป็นช่วงที่พบบ่อย: ยาวพอให้ SMS ที่มาช้ายังมาถึง สั้นพอที่โค้ดที่รั่วไหลมักตายไปแล้ว แสดงเวลาที่เหลือให้ผู้ใช้เห็น เพื่อให้ข้อความที่ช้าไม่ถูกอ่านว่าเป็นโฟลว์ที่พัง

!

จับคู่การหมดอายุที่สั้นกับช่วงพักการส่งซ้ำ ไม่เช่นนั้นผู้ใช้จะกดส่งซ้ำรัว ๆ เมื่อข้อความมาช้า และเพิ่มต้นทุน SMS ของคุณเป็นทวีคูณ

จำกัดอัตราในทุกมิติ

การจำกัดอัตราคือสิ่งที่หยุดทั้งการเดาโค้ดแบบเดารหัสและการใช้ปลายทางส่งของคุณในทางที่ผิด (ซึ่งเสียเงินคุณและอาจทำให้ผู้ส่งของคุณถูกตั้งค่าสถานะ) จำกัดต่อหมายเลขโทรศัพท์ ต่อ IP และต่อบัญชี ทั้งด้านการส่งและการตรวจสอบ

  • ความพยายามตรวจสอบ: จำกัดจำนวนครั้งต่อโค้ด (เช่น 5) แล้วทำให้ใช้ไม่ได้และบังคับส่งซ้ำ
  • คำขอส่ง: มีช่วงพักระหว่างการส่งและเพดานต่อวันต่อหมายเลข
  • ตัวป้องกันระดับรวม: การจำกัดต่อ IP และต่อบัญชีเพื่อลดทอนการใช้ในทางที่ผิดแบบอัตโนมัติ
  • เพิ่มการถอยแบบเอ็กซ์โพเนนเชียลหรือ CAPTCHA เมื่อถึงเพดานซ้ำ ๆ

จัดการการลองใหม่และช่องทางสำรอง

SMS เป็นแบบพยายามอย่างดีที่สุด ดังนั้นโฟลว์ที่ดีสันนิษฐานว่าบางข้อความจะไม่มาถึง เสนอการส่งซ้ำหลังช่วงพัก และหลังจากความล้มเหลวของ SMS หนึ่งหรือสองครั้ง ให้ยกระดับไปยังช่องทางสำรอง — โทรศัพท์เสียงที่อ่านโค้ด, WhatsApp หรืออีเมล — ซึ่งเป็นสิ่งที่ Verify API แบบมีการจัดการทำอัตโนมัติพอดี

ทำให้สถานะความล้มเหลวมีความเป็นมนุษย์: เส้นทาง "ไม่ได้รับหรือ?" ที่ชัดเจน วิธีเปลี่ยนหมายเลข และการติดต่อฝ่ายสนับสนุนหลังจากล้มเหลวซ้ำ

  1. 1

    ครั้งแรก: SMS

    ส่งโค้ดและเริ่มนับถอยหลังที่มองเห็นได้พร้อมช่วงพักการส่งซ้ำ

  2. 2

    ส่งซ้ำเมื่อร้องขอ

    อนุญาตให้ส่งซ้ำหลังช่วงพัก; ทำให้โค้ดก่อนหน้าใช้ไม่ได้เมื่อออกโค้ดใหม่

  3. 3

    ยกระดับช่องทาง

    หลังจาก SMS ล้มเหลวซ้ำ ให้เสนอเสียงหรือช่องทางสำรองเพื่อส่งการยืนยันเดียวกัน

  4. 4

    เสนอทางออก

    ให้ผู้ใช้แก้ไขหมายเลขหรือติดต่อฝ่ายสนับสนุน แทนที่จะเดินชนทางตัน

ปรับปรุง UX โดยไม่ลดความปลอดภัย

การสัมผัสเล็ก ๆ ช่วยเพิ่มอัตราการทำสำเร็จ: ใช้ WebOTP API และรูปแบบเติมโค้ด SMS อัตโนมัติเพื่อให้เบราว์เซอร์มือถืออ่านโค้ดได้ รักษาถ้อยคำข้อความให้สอดคล้อง (บางแพลตฟอร์มแคชผู้ส่งที่เชื่อถือได้) และอย่าใส่อะไรนอกจากโค้ดและชื่อแอปของคุณในข้อความ หลีกเลี่ยงลิงก์ในข้อความ OTP — มันฝึกให้ผู้ใช้คลิก และไปสะดุดตัวกรองสแปมของผู้ให้บริการเครือข่าย

  • รองรับ WebOTP / การเติมโค้ดครั้งเดียวอัตโนมัติบนมือถือ
  • รักษาข้อความให้น้อยที่สุด: ชื่อแอป + โค้ด ไม่มีการตลาด ไม่มีลิงก์
  • แปลข้อความเป็นภาษาท้องถิ่น แต่รักษารูปแบบโค้ดให้คงที่

คำถามที่พบบ่อย

OTP ควรใช้ได้นานแค่ไหน?+

ห้าถึงสิบนาทีเป็นช่วงที่พบบ่อย ยาวพอที่จะรอด SMS ที่มาช้า แต่สั้นพอที่โค้ดที่รั่วไหลมักหมดอายุไปแล้ว แสดงเวลาที่เหลือเสมอ เพื่อให้ข้อความที่ช้าไม่ดูเหมือนโฟลว์ที่พัง

ฉันควรอนุญาตให้พยายามตรวจสอบกี่ครั้ง?+

จำกัดการพยายามต่อโค้ดไว้ประมาณห้าครั้ง แล้วทำให้โค้ดใช้ไม่ได้และต้องส่งใหม่ รวมสิ่งนั้นเข้ากับการจำกัดอัตราต่อหมายเลข ต่อ IP และต่อบัญชี ทั้งด้านการส่งและการตรวจสอบ เพื่อหยุดการเดารหัสและการใช้ปลายทางส่งในทางที่ผิด

ฉันควรใส่ลิงก์ในข้อความ OTP ไหม?+

ไม่ ให้ข้อความ OTP มีแค่ชื่อแอปและโค้ดของคุณ ลิงก์ฝึกให้ผู้ใช้คลิก อาจทำให้โค้ดรั่วผ่าน referrer และมักไปกระตุ้นการกรองสแปมของผู้ให้บริการเครือข่ายซึ่งทำร้ายอัตราการส่งถึง

OTP ทาง SMS ปลอดภัยพอในตัวเองไหม?+

OTP ทาง SMS เป็นการยกระดับที่มีความหมายเหนือรหัสผ่านเพียงอย่างเดียว แต่เปราะบางต่อ SIM swap และการดักฟัง สำหรับบัญชีมูลค่าสูง ให้เสนอปัจจัยที่แข็งแกร่งกว่าอย่าง Passkey หรือ TOTP และถือว่า SMS เป็นระบบสำรอง — ดูคู่มือทางเลือกแทน OTP

EdgeGigs

ทำโฟลว์ OTP ให้ถูกต้องตั้งแต่ครั้งแรก

จ้างนักพัฒนาที่ผ่านการคัดกรองบน EdgeGigs เพื่อสร้างการสร้างโค้ดที่ปลอดภัย การหมดอายุ การจำกัดอัตรา และการสำรองในเว็บหรือแอปมือถือของคุณ

ค้นหานักพัฒนาบน EdgeGigs