แยก Login กับ Recovery แต่เชื่อมทางเข้าให้ชัด
Login เป็นกระบวนการยืนยันข้อมูลเพื่อสร้างเซสชัน ส่วน Reset Password เป็นกระบวนการพิสูจน์สิทธิ์ผ่านช่องทางกู้คืนแล้วเปลี่ยน Credential การแยกสอง Flow ทำให้ขอบเขต ความเสี่ยง และทีมรับผิดชอบอ่านง่ายขึ้น
หน้า Login ควรมีลิงก์ไป Recovery แต่ไม่ควรวาดรายละเอียดการส่งอีเมลทั้งหมดใน Diagram เดียว ถ้าผู้อ่านต้องเข้าใจทั้งคู่ให้ใช้ Related Link หรือ Hub ที่ชี้ไปสองเทมเพลต
เส้นทาง Login ที่ไม่เปิดเผยสถานะบัญชีเกินจำเป็น
รับ Identifier และรหัสผ่านผ่านการเชื่อมต่อที่ปลอดภัย ตรวจ Rate Limit และสถานะที่จำเป็นฝั่ง Server จากนั้นตอบข้อความกลางเมื่อข้อมูลไม่ถูกต้อง เพื่อลดการเดาว่าบัญชีใดมีอยู่
เมื่อผ่านจึงสร้างเซสชันตามสิทธิ์และพาไปปลายทางที่อนุญาต Log ต้องไม่เก็บรหัสผ่าน Token หรือข้อมูล Markdown ส่วนตัว
- รับข้อมูลเข้าสู่ระบบ
- ตรวจข้อจำกัดและสถานะ
- ตรวจ Credential
- สร้างเซสชันหรือปฏิเสธอย่างปลอดภัย
เส้นทาง Reset Password และอายุของลิงก์
แบบฟอร์มกู้คืนควรตอบข้อความเดียวกันไม่ว่าอีเมลมีบัญชีหรือไม่ ระบบออก Token ที่คาดเดาไม่ได้ ใช้ครั้งเดียว และหมดอายุ ส่งผ่านช่องทางที่ยืนยันไว้โดยไม่ใส่ข้อมูลลับเกินจำเป็น
เมื่อผู้ใช้เปิดลิงก์ ให้ตรวจลายเซ็น อายุ และสถานะการใช้งานก่อนแสดงฟอร์มตั้งรหัสผ่าน หลังเปลี่ยนสำเร็จควรพิจารณายกเลิกเซสชันเดิมและแจ้งเตือนเจ้าของบัญชีตามนโยบายจริง
- รับคำขอกู้คืน
- ออกและส่ง Token แบบจำกัดอายุ
- ตรวจ Token ก่อนรับรหัสผ่านใหม่
- เปลี่ยน Credential และยกเลิก Token
Checklist สำหรับทบทวนกับทีม Security และ Support
Flowchart อธิบายลำดับ แต่ไม่แทน Threat Model หรือการทดสอบระบบ ทีมต้องตรวจ Authorization, Rate Limit, Session, Audit และวิธีตอบ Incident จาก Implementation จริง
ให้ Support ทบทวนข้อความผิดพลาดและข้อมูลที่ใช้ Escalate เพื่อให้ช่วยผู้ใช้ได้โดยไม่ขอข้อมูลลับ ส่วน Product ควรตรวจว่าทางกู้คืนเข้าถึงได้และไม่ทำให้ข้อมูลใน Guest Editor สูญหายเมื่อเชิญ Login
- ข้อความไม่ยืนยันว่าบัญชีมีอยู่
- Token ใช้ครั้งเดียวและหมดอายุ
- สิทธิ์ตรวจฝั่ง Server
- Session เดิมมีนโยบายชัด
- Log ไม่มี Credential หรือ Secret