ปฏิบัติต่อเลขบัญชีลับเป็นข้อมูลรับรอง: ตรวจสอบมัน

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

ทำบัญชีสิ่งที่การครอบครองให้จริง

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

รูปแบบทั่วไปพูดง่าย: ข้อมูลรับรองแบบ bearer คือข้อมูลที่ผู้ถือใช้ได้โดยไม่ต้องพิสูจน์การครอบครองคีย์เข้ารหัสแยกต่างหาก และนั่นคือความแตกต่างที่ RFC 6750 กำหนดสำหรับโทเค็น นี่คือการเปรียบเทียบ ไม่ใช่ข้ออ้างว่าบริการที่อิงหมายเลขใช้ OAuth ถ้าผู้ถือไม่ต้องการอย่างอื่น ให้ถือว่าหมายเลขเป็นความลับแบบ bearer และจำแนกส่วนที่เหลือของการออกแบบตามนั้น

ปกป้องมันเป็นความลับ ไม่ใช่เป็นข้อมูลอ้างอิง

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

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

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

ตรวจสอบความต้านทานการเดาและการจำกัดอัตราไปพร้อมกัน

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

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

# one attempt, then read the response and any counter or delay
# do not script repeated guesses against a live account
curl -i -X POST https://portal.example.invalid/login -d "account=000000000000"

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

วางแผนการหมุนเวียนและการเพิกถอนก่อนจำเป็น

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

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

จัดทำเอกสารการตัดสินใจและตรวจสอบซ้ำภายหลัง

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

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

ก่อนบันทึก:

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