เจาะลึกระบบรีเซ็ตรหัสผ่าน API ความปลอดภัยและการจัดการ Rate Limit
แนวทางการออกแบบระบบรีเซ็ตรหัสผ่านอีเมลอย่างปลอดภัย จัดการ API 429 Rate Limit ควบคุมสถานะบัญชี และป้องกันการโจมตีแบบ Enumeration ตามมาตรฐาน OWASP
ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง
- ปฏิบัติกับคำขอรีเซ็ตรหัสผ่านเป็นขั้นตอนการกู้คืนที่มีการตรวจสอบได้ ไม่ใช่แค่การส่งอีเมลทันที
- ป้องกันการเดาบัญชี (Non-enumeration) ด้วยการคืนค่าตอบกลับแบบเดียวกันไม่ว่าบัญชีจะมีอยู่จริงหรือไม่
- กำหนดให้มีโทเค็นใช้งานได้จริงเพียงหนึ่งอันต่อบัญชีในช่วงเวลานโยบายเพื่อความปลอดภัย
- แยกสถานะความถูกต้องของผู้รับและการส่งข้อความออกจากกันอย่างเด็ดขาดเพื่อป้องกันบัญชีถูกล็อก
การจัดการคำขอกู้คืนรหัสผ่านควรถูกมองว่าเป็นกระบวนการกู้คืนที่มีระบบตรวจสอบย้อนกลับ (auditable recovery workflow) มากกว่าการสั่งส่งอีเมลแบบทันที ระบบควรยอมรับคำขอโดยไม่เปิดเผยสถานะของบัญชี บังคับใช้ระยะเวลาพัก (cooldown) ต่อบัญชี และให้ตัวทำงานเบื้องหลัง (durable worker) จัดการกับค่า Retry-After หลังจากได้รับรอด 429 โดยไม่ต้องสร้างโทเค็นรีเซ็ตรหัสผ่านชุดที่สองขึ้นมาใหม่ ข้อจำกัดสำคัญในระบบบริการลูกค้าคือ การจัดส่งอีเมลอาจมีความไม่แน่นอน แต่ผลลัพธ์ด้านความปลอดภัยต้องมีความแน่นอนเสมอ
คำตอบสั้นๆ สำหรับนักพัฒนาคือ คืนค่าตอบกลับแบบทั่วไปที่เหมือนกันทุกประการสำหรับบัญชีที่มีอยู่จริงและไม่มีอยู่จริง สร้างความท้าทายในการกู้คืน (recovery challenge) อย่างมากที่สุดหนึ่งรายการในช่วงเวลานโยบาย และบันทึกความพยายามในการจัดส่งแยกต่างหากจากการสร้างโทเค็น รหัสสถานะ HTTP 429 เป็นเพียงการบอกว่าความพยายามครั้งถัดไปจะเกิดขึ้นเมื่อใด แต่มันไม่ได้ให้สิทธิ์ในการสร้างลิงก์ใหม่ การตีกลับถาวรหรือที่อยู่อีเมลที่ไม่ถูกต้องซึ่งได้รับการยืนยันจากผู้ดูแลระบบจะปิดเส้นทางการส่งอีเมลและส่งเค้าโครงไปยังกระบวนการกู้คืนบัญชีที่ทีมสนับสนุนตรวจสอบแล้ว
ความแตกต่างนี้ทำให้ระบบมีคุณสมบัติที่มีประโยชน์สามประการพร้อมกัน ผู้ใช้จะไม่สามารถสร้างพายุคำขอซ้ำจากการคลิกปุ่มส่งซ้ำได้ ตัวทำงานเบื้องหลังสามารถหยุดทำงานกะทันหันหลังจากการเรียกเครือข่ายโดยไม่ทำให้สถานะการกู้คืนเสียหาย และเจ้าหน้าที่ฝ่ายสนับสนุนสามารถอธิบายได้ว่าเหตุใดอีเมลจึงหยุดส่งโดยไม่ต้องอ่านข้อมูลลับหรือพยายามประกอบเหตุการณ์ขึ้นใหม่จากบันทึกของแอปพลิเคชัน การส่งข้อความแบบครั้งเดียวพอดี (Exactly once delivery) เป็นสิ่งที่เป็นไปไม่ได้เมื่อข้ามขอบเขต HTTP แต่การเปลี่ยนผ่านสถานะแบบครั้งเดียวพอดีสามารถทำได้ด้วยข้อจำกัดความเป็นเอกลักษณ์ (uniqueness constraints) การอัปเดตแบบมีเงื่อนไข และบันทึกการตรวจสอบที่เขียนเพิ่มได้อย่างเดียว (append-only audit record)
ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง
invariant ข้อแรกคือการป้องกันการระบุตัวตน (Non-enumeration) องค์กร OWASP แนะนำให้ใช้ข้อความตอบกลับและเวลาในการตอบสนองที่สม่ำเสมอสำหรับคำขอรีเซ็ตรหัสผ่าน ไม่ว่าบัญชีนั้นจะมีอยู่จริงหรือไม่ ดังนั้นตัวจัดการคำขอสาธารณะจึงควรตอบรับคำขอก่อนที่จะเปิดเผยการตัดสินใจในการจัดส่งใดๆ ตัวจัดการอาจจัดคิวงานภายในเฉพาะสำหรับบัญชีที่ตรงกัน แต่กิ่งก้านสาขานั้นต้องไม่เปลี่ยนแปลงการตอบสนองที่สังเกตได้จากภายนอก
invariant ข้อที่สองคือการมีโทเค็นที่ใช้งานได้หนึ่งชุดต่อบัญชีและวัตถุประสงค์ในการกู้คืน ระบบควรจัดเก็บเฉพาะแฮชของโทเค็นสุ่มที่มีความปลอดภัยทางเข้ารหัส กำหนดวันหมดอายุ ทำให้ใช้งานได้ครั้งเดียว และยกเลิกการใช้งานหลังจากการรีเซ็ตรหัสผ่านสำเร็จ คำขอซ้ำควรจะอ้างอิงถึงโทเค็นเดิมที่ยังไม่หมดอายุหรือแทนที่โดยอัตโนมัติตามนโยบายที่บันทึกไว้ การสร้างโทเค็นใหม่ตามการคลิกแต่ละครั้งแบบสุ่มสี่สุ่มห้าจะทิ้งข้อมูลรับรองที่ถูกต้องหลายชุดไว้ในกล่องจดหมายและทำให้การตรวจสอบเหตุการณ์มีความคลุมเครือโดยใช่เหตุ
invariant ข้อที่สามคือ ความถูกต้องของผู้รับและการส่งข้อความคือเครื่องจักรสถานะ (state machines) คนละตัวกัน รหัส HTTP 429 หมายถึงปลายทางกำลังจำกัดอัตราคำขอ มาตรฐาน RFC 6585 ระบุว่าการตอบ 429 อาจรวมถึงส่วนหัว Retry-After ซึ่งตาม RFC 9110 นิยามว่าเป็นจำนวนวินาทีที่ต้องหน่วงเวลาหรือวันที่แบบ HTTP ไม่มีข้อความใดระบุว่าที่อยู่อีเมลนั้นไม่ถูกต้อง ในทางกลับกัน สถานะ SMTP ขั้นสูงเช่น 5.1.1 ระบุความล้มเหลวของที่อยู่อีเมลอย่างถาวร ในขณะที่สถานะชั่วคราวเช่น 4.x.x ไม่ได้ให้เหตุผลในการระงับอีเมลอย่างถาวร การนำสัญญาณเหล่านี้มารวมกันจะเปลี่ยนเหตุการณ์ความจุชั่วคราวให้กลายเป็นเรื่องของการล็อกบัญชีผู้ใช้
"Treat a password-reset request as an auditable recovery workflow, not as a synchronous email send."
Dev.to Article
สำหรับการสนับสนุนขององค์กร การระงับการส่งอีเมลจำเป็นต้องมีที่มาที่ไป (provenance) บันทึกว่าหลักฐานมาจากสถานะการจัดส่งถาวร การกระทำของผู้ดูแลระบบที่ได้รับการตรวจสอบสิทธิ์แล้ว หรือการแก้ไขที่อยู่อีเมลภายหลัง บันทึกตัวระบุเหตุการณ์และเวลา ห้ามจัดเก็บโทเค็นรีเซ็ตรหัสผ่านไว้ในข้อมูลการตรวจสอบ (audit payload) นี่คือวินัยเดียวกันกับที่คาดหวังจากสมุดบัญชี ยอดคงเหลือปัจจุบันมีประโยชน์ แต่ไม่ใช่สิ่งทดแทนรายการบัญชีที่สร้างยอดนั้นขึ้นมา
การเข้าใจการทำงานเบื้องหลังของ API Rate Limit และการจัดการสถานะความปลอดภัยช่วยให้สถาปนิกซอฟต์แวร์สามารถออกแบบระบบที่ป้องกันการโจมตีแบบ Brute-force และ Enumeration ได้อย่างมีประสิทธิภาพ การแยกตารางฐานข้อมูลสำหรับ Outbox และ Audit Log ออกจากกันช่วยป้องกันความเสี่ยงที่ข้อมูลความปลอดภัยจะรั่วไหลผ่านบันทึกข้อผิดพลาดของระบบ
การออกแบบที่ถูกเลือกคือการใช้ transactional outbox ร่วมกับตารางความท้าทายในการกู้คืน ตารางสถานะผู้รับ และบันทึกความพยายามแบบเขียนเพิ่มเท่านั้น ธุรกรรมบนเว็บจะสร้างหรือค้นหาความท้าทายที่ใช้งานอยู่และแทรกรายการ outbox ที่มีคีย์เฉพาะ ตัวทำงานจะอ้างสิทธิ์ในรายการนั้น ตรวจสอบการระงับอีกครั้ง ดำเนินการส่งผ่านระยะไกลหนึ่งครั้ง และบันทึกผลลัพธ์ การรับข้อความตีกลับ (bounce ingestion) เป็นเส้นทางที่ตรวจสอบสิทธิ์แยกต่างหากเพราะมาถึงทีหลังและมีขอบเขตความเชื่อถือและการเล่นซ้ำที่แตกต่างกัน
ที่มา: Dev.to
พบข้อมูลผิดพลาดในบทความนี้? แจ้งปัญหาบทความนี้
ความคิดเห็น
แสดงความคิดเห็น