เครื่องมือสำหรับนักพัฒนา · ตัวสร้าง UUID
UUID แบบสุ่มปลอดภัยสำหรับการรีเซ็ตรหัสผ่านหรือโทเค็นเซสชันหรือไม่
· เหตุใดจึงสำคัญ
uuid การเข้ารหัส เบราว์เซอร์-apis
v4 UUID จาก CSPRNG มีเอนโทรปีมากมาย แล้วเหตุใดผู้ตรวจสอบความปลอดภัยจึงยังขมวดคิ้วที่โทเค็น UUID โพสต์นี้แยกคำถามเอนโทรปีออกจากคำถามการออกแบบ
ลิงก์รีเซ็ตที่ใช้ UUID ของแถว — ทางลัดทั่วไปและเหตุผลสองประการที่แตกต่างกันมากที่อาจไม่ปลอดภัย
ทางลัดทั่วไป: ใช้ตัวระบุแถว UUID ของผู้ใช้เป็นโทเค็นรีเซ็ตรหัสผ่าน ตารางมีคอลัมน์ uuid มันมีเอกลักษณ์ มันยากที่จะคาดเดา (ถ้าเป็น v4) URL คือ /reset หรือไม่ โทเค็น=550e8400-e29b-41d4-a716-446655440000 ผู้ตรวจสอบความปลอดภัยปฏิเสธทันที ไม่ใช่เพราะ UUID นั้นอ่อนแอ แต่เป็นเพราะมันเชื่อมโยงข้อกังวลสองประการที่ควรแยกจากกัน แถว UUID มีความเสถียรและมักจะปรากฏต่อสาธารณะ (ใน URL, API, บันทึก) โทเค็นการรีเซ็ตควรเป็นแบบใช้ครั้งเดียวและเป็นความลับ การใช้แถว UUID ซ้ำเป็นโทเค็นหมายความว่าข้อมูลประจำตัวของผู้ใช้และข้อมูลประจำตัวที่รีเซ็ตเป็นค่าเดียวกัน และข้อมูลรับรองจะคงอยู่ตลอดไปแทนที่จะหมดอายุ ผู้โจมตีที่ทราบ ID ของผู้ใช้สามารถทำการรีเซ็ตได้ ผู้ใช้ที่คัดลอกและวางลิงก์รีเซ็ตเมื่อห้าปีที่แล้วยังคงสามารถใช้งานได้ สิ่งเหล่านี้เป็นข้อบกพร่องด้านการออกแบบ ไม่ใช่ข้อบกพร่องด้านเอนโทรปี
การตรวจสอบเอนโทรปี: 122 บิตสุ่ม - เหตุใด CSPRNG ที่สร้าง v4 จึงไม่สามารถเดาได้ด้วยกำลังดุร้าย
จำเป็นต้องมีการตรวจสอบการสุ่มแต่ยังไม่เพียงพอ เวอร์ชัน 4 สงวนบิตเวอร์ชันสี่บิตและบิตตัวแปรสองบิต โดยปล่อยให้ 128 - 4 - 2 = 122 ตำแหน่งสุ่ม เมื่อการใช้งานเติมฟิลด์อื่นๆ แบบสุ่ม ที่มานั้นไม่ได้กล่าวถึงการหมดอายุ การจัดเก็บ หรือการอนุญาตแต่อย่างใด การตรวจสอบตัวสร้างจะถามว่าฟิลด์เหล่านั้นมาจาก CSPRNG แทนที่จะเป็น Math.random หรือการประทับเวลาหรือไม่ ToolAcre เป็นไปตามขอบเขตของตัวสร้างนั้น การตรวจสอบการออกแบบยังคงเป็นแบบเฉพาะแอปพลิเคชัน: ข้อมูลรับรองการรีเซ็ตจำเป็นต้องมีวงจรการใช้งานที่แยกจากกัน การนำเสนอที่จัดเก็บแบบทางเดียว การทำให้ใช้งานไม่ได้หลังจากใช้งานสำเร็จ และการหมดอายุที่เลือกจากนโยบายความเสี่ยงของบริการ การใช้รหัสเรกคอร์ดถาวรของผู้ใช้ซ้ำจะล้มเหลวในการแยกแม้ว่ารหัสจะถูกสร้างขึ้นอย่างปลอดภัยก็ตาม
การตรวจสอบตัวสร้าง: โดยที่โทเค็น UUID ล้มเหลวจริง ๆ — การสร้างตาม Math.random, การประทับเวลา v1 และที่อยู่ MAC และเมล็ดที่คาดเดาได้
ตัวอย่างการทำงาน: รูปแบบการรีเซ็ตรหัสผ่านที่ล้มเหลว แล้วผ่าน การตรวจสอบสามครั้ง ไม่ผ่านการตรวจสอบเอนโทรปี: เซิร์ฟเวอร์ออกโทเค็นการรีเซ็ตผ่าน Math.random() ซึ่งบรรจุเป็น v4 UUID ผู้โจมตีสังเกตโทเค็นสามอันและทำนายโทเค็นที่สี่ ตรวจสอบตัวสร้างไม่สำเร็จ: เซิร์ฟเวอร์ใช้ v1 UUID เป็นโทเค็นการรีเซ็ต รวมถึงการประทับเวลาการสร้างและที่อยู่ MAC ในค่า ผู้โจมตีอ่านการประทับเวลา เรียนรู้เมื่อมีการออกการรีเซ็ต และจำกัดหน้าต่างการค้นหาให้แคบลง ผ่านการตรวจสอบเอนโทรปีแต่ไม่ผ่านการตรวจสอบการออกแบบ: เซิร์ฟเวอร์ใช้ v4 UUID จาก crypto.getRandomValues แต่เก็บไว้ในข้อความธรรมดาในฐานข้อมูลและไม่ได้ตั้งค่าการหมดอายุ ผู้โจมตีที่ละเมิดฐานข้อมูลจะอ่านโทเค็นการรีเซ็ตและใช้เพื่อรีเซ็ตบัญชีในสัปดาห์ต่อมา เช็คทั้งสามนั้นมีความเป็นอิสระ คุณต้องผ่านทั้งสามอย่าง
การตรวจสอบการออกแบบ: ตัวระบุเทียบกับข้อมูลรับรอง - เหตุใดจึงนำคีย์หลักของเรคคอร์ดกลับมาใช้ใหม่เป็นคู่ความลับสองสิ่งที่ควรหมุนเวียนอย่างอิสระ
รูปแบบโทเค็นการรีเซ็ตที่ผ่านการตรวจสอบเอนโทรปีและตัวสร้าง แต่ไม่ผ่านการตรวจสอบการออกแบบ (ไม่มีการแฮช ไม่มีการหมดอายุ ไม่มีการใช้งานที่ไม่ถูกต้องต่อการใช้งาน) ยังคงมีความเสี่ยงอยู่ การจัดการโทเค็นฝั่งเซิร์ฟเวอร์: เมื่อผู้ใช้ร้องขอการรีเซ็ตรหัสผ่าน ให้สร้างโทเค็นแบบสุ่มใหม่ (ไม่ใช่แถว UUID) จาก crypto.getRandomValues จัดเก็บการแสดงแบบทางเดียวแทนมูลค่าที่นำเสนอ ตั้งค่าการหมดอายุเฉพาะนโยบาย และทำให้บันทึกเป็นโมฆะหลังจากใช้งานสำเร็จ เมื่อผู้ใช้คลิกลิงก์ ให้ค้นหาผู้ใช้ทางอีเมล ดึงข้อมูลแฮชที่เก็บไว้ เปรียบเทียบโทเค็นที่ให้มากับแฮช ตรวจสอบการหมดอายุ และดำเนินการรีเซ็ตเฉพาะเมื่อโทเค็นถูกต้องและยังไม่หมดอายุ ทำให้โทเค็นใช้ไม่ได้ทันที (ลบออกหรือทำเครื่องหมายว่าใช้แล้ว) เพื่อไม่ให้นำมาใช้ซ้ำได้ อย่าบันทึกโทเค็นดิบ บันทึกเฉพาะ ID ผู้ใช้และการดำเนินการ
การจัดการโทเค็นฝั่งเซิร์ฟเวอร์ — จัดเก็บแฮช กำหนดวันหมดอายุ ทำให้ใช้งานไม่ได้ และไม่บันทึกค่าดิบ
โทเค็นไม่ควรปรากฏในข้อความแสดงข้อผิดพลาดหรือในฐานข้อมูลเว้นแต่จะมีการแฮช การออกแบบการตรวจสอบสิทธิ์แบบเต็มนั้นอยู่นอกเหนือขอบเขตของบทความ UUID แต่หลักการมีอยู่ว่า: โทเค็นสุ่ม 122 บิตไม่ใช่โทเค็นการเข้าถึงโดยเนื้อแท้ การสุ่มเป็นส่วนที่ง่าย ตัวสร้าง ToolAcre ให้ UUID ที่สนับสนุน CSPRNG แก่คุณ ส่วนที่ยากคือการออกแบบ: การแฮชก่อนการจัดเก็บ การตั้งเวลาหมดอายุ การทำให้การใช้งานเป็นโมฆะ การป้องกันการนำ ID ถาวรมาใช้ซ้ำเป็นความลับชั่วคราว การตรวจสอบว่าใครเข้าถึงอะไรและเมื่อใด ผู้ตรวจสอบความปลอดภัยที่อนุมัติโครงร่างลิงก์รีเซ็ตโดยอิงตามเอนโทรปีของโทเค็นเพียงอย่างเดียวกำลังข้ามการวิเคราะห์ส่วนที่เหลือ นักพัฒนาซอฟต์แวร์ที่คิดว่า CSPRNG ที่ได้รับการสนับสนุน UUID นั้นเพียงพอสำหรับลิงก์รีเซ็ตรหัสผ่านที่ไม่มีการแฮช การหมดอายุ และการทำให้ใช้งานไม่ได้ถือเป็นการประมาณค่าภัยคุกคามต่ำเกินไป การสุ่มป้องกันการคาดเดา การออกแบบป้องกันการเล่นซ้ำ การหมดอายุ และการใช้งานในทางที่ผิด
ตัวอย่างการทำงาน — ทบทวนโครงร่างลิงก์รีเซ็ตกับการตรวจสอบแต่ละครั้งและเขียนส่วนที่อ่อนแอใหม่
ตัวสร้าง ToolAcre ทำส่วนที่สุ่มถูกต้อง แอปพลิเคชันต้องทำส่วนการออกแบบให้ถูกต้อง ทดสอบโค้ดรีเซ็ตลิงก์ของคุณเองกับการตรวจสอบทั้งสามรายการ: ใช้ CSPRNG (crypto.getRandomValues, crypto.randomUUID หรือไลบรารีการเข้ารหัส) ไม่ใช่ Math.random หรือไม่ โทเค็นมีเวลาหมดอายุหรือไม่? โทเค็นถูกแฮชก่อนจัดเก็บหรือไม่ โทเค็นใช้งานไม่ได้หลังการใช้งานหรือไม่ รหัสหลีกเลี่ยงการใช้ ID ถาวรของผู้ใช้ซ้ำเป็นโทเค็นชั่วคราวหรือไม่ หากคุณตอบว่าใช่ทุกข้อ การออกแบบลิงก์รีเซ็ตของคุณก็ดูดี ตัวสร้าง ToolAcre คือส่วน CSPRNG ส่วนที่เหลือเป็นรหัสแอปพลิเคชันที่คุณต้องตรวจสอบอย่างละเอียด การทำความเข้าใจการรักษาความปลอดภัยสามชั้นช่วยให้คุณตรวจสอบไลบรารีและเฟรมเวิร์ก UUID ของบุคคลที่สามได้ เมื่อคุณประเมินไลบรารี ให้ตรวจสอบว่าไลบรารีใช้ CSPRNG (การตรวจสอบเอนโทรปี) ไม่ใช่แหล่งที่มาแบบสุ่มที่ไม่รัดกุม ตรวจสอบว่าเอกสารนั้นใช้แหล่งใดและทำไม (ตรวจสอบเครื่องกำเนิดไฟฟ้า)
สิ่งนี้ไม่ครอบคลุม — การออกแบบการรับรองความถูกต้องแบบเต็ม MFA และการจำกัดอัตรา ซึ่งมีความสำคัญมากเท่ากับเอนโทรปีของโทเค็น
ตรวจสอบว่าโค้ดตัวอย่างและเอกสารประกอบเน้นหลักการออกแบบ: การแฮช การหมดอายุ การทำให้ใช้ไม่ได้ (การตรวจสอบการออกแบบ) ห้องสมุดที่ผ่านการตรวจสอบทั้งสามนั้นหาได้ยาก ส่วนใหญ่มุ่งเน้นไปที่เอนโทรปีเพียงอย่างเดียว ตัวสร้าง ToolAcre ผ่านการตรวจสอบเอนโทรปีและตัวสร้างโดยใช้ crypto.getRandomValues การตรวจสอบการออกแบบถือเป็นความรับผิดชอบของคุณ ห้องสมุดไม่สามารถทราบข้อกำหนดการหมดอายุหรือกลยุทธ์การแฮชของคุณได้ การดีบักระบบรีเซ็ตลิงค์ที่เสียหายมักจะเผยให้เห็นความล้มเหลวหนึ่งในสามประการ หากผู้ใช้รายงานว่าได้รับลิงก์รีเซ็ตที่ใช้งานไม่ได้อีกต่อไป ปัญหาน่าจะหมดอายุ: โทเค็นออกแล้ว แต่หมดอายุก่อนที่ผู้ใช้จะคลิกลิงก์ หากโทเค็นถูกนำมาใช้ซ้ำหลายครั้ง ใช้งานไม่ได้จะใช้งานไม่ได้ หากโทเค็นปรากฏในข้อความแสดงข้อผิดพลาดหรือเอาต์พุตการแก้ไขข้อบกพร่อง แสดงว่าการบันทึกรั่วไหล หากลิงก์รีเซ็ตใช้งานได้สำหรับผู้ใช้รายหนึ่งแต่ใช้ไม่ได้กับผู้ใช้รายอื่น อาจเกิดปัญหาความล่าช้าในการจำลองฐานข้อมูลหรือเขตเวลาในการคำนวณการหมดอายุ หากคำขอรีเซ็ตที่ถูกต้องล้มเหลวแบบสุ่ม CSPRNG อาจใช้งานไม่ได้ (พบไม่บ่อย)
ประเด็นสำคัญ: การสุ่มเป็นส่วนที่ง่าย - ตัวสร้าง ToolAcre ให้ CSPRNG-backed UUID แก่คุณ ที่เหลือคือวินัยในการออกแบบ
เริ่มต้นด้วยการบันทึก: เปิดใช้งานบันทึกการตรวจสอบโดยละเอียดสำหรับการสร้างและการตรวจสอบลิงก์รีเซ็ต จากนั้นจำลองปัญหาและติดตามโฟลว์ ตัวสร้าง ToolAcre ช่วยให้มั่นใจว่าการตรวจสอบสองรายการแรกผ่าน การแก้ไขปัญหาการรีเซ็ตลิงค์มักจะอยู่ในหมวดหมู่การออกแบบเกือบทุกครั้ง แนวทางปฏิบัติที่ดีที่สุดสำหรับระบบลิงก์รีเซ็ตที่ใช้งานจริง ได้แก่: สร้างโทเค็นแบบสุ่มใหม่สำหรับคำขอรีเซ็ตทุกครั้ง ไม่ใช่นำโทเค็นเก่ามาใช้ซ้ำ จัดเก็บการแสดงแบบทางเดียวควบคู่ไปกับบัญชีและข้อมูลเมตาการสร้าง จากนั้นเลือกวันหมดอายุจากนโยบายความเสี่ยงที่จัดทำเป็นเอกสารของบริการ ทำให้โทเค็นใช้ไม่ได้ทันทีหลังจากการยืนยันสำเร็จ บันทึกคำขอรีเซ็ตและความสำเร็จสำหรับการตรวจสอบ ใช้การจำกัดอัตราเพื่อป้องกันการโจมตีแบบเดรัจฉาน ส่งลิงก์รีเซ็ตทางอีเมลเท่านั้น ไม่ใช่ SMS หรือช่องที่ไม่ได้เข้ารหัส แจ้งให้ผู้ใช้ทราบถึงความพยายามในการรีเซ็ตรหัสผ่าน (เพื่อให้พวกเขาสามารถตรวจจับการรีเซ็ตที่ไม่ได้รับอนุญาต) เครื่องกำเนิด ToolAcre ให้การสุ่มแก่คุณ การปฏิบัติตามแนวทางปฏิบัติเหล่านี้จะทำให้คุณได้รับความปลอดภัย