โดยทั่วไปคุณมีข้อกำหนดสามประการ:
- ไม่ควรใช้คีย์เดียวกันสำหรับหลาย ๆ อินสแตนซ์ของลูกค้า
- ไม่ควรสร้างคีย์ที่ถูกต้องใหม่และ
- ไม่ควรขโมยกุญแจของลูกค้าที่ชอบด้วยกฎหมาย
ส่วนแรกควรตรงไปตรงมา: อย่าให้ผู้เล่นสองคนลงชื่อเข้าใช้เซิร์ฟเวอร์เดียวกันด้วยรหัสเดียวกันในเวลาเดียวกัน นอกจากนี้คุณยังสามารถให้เซิร์ฟเวอร์แลกเปลี่ยนข้อมูลเกี่ยวกับผู้ใช้ที่เข้าสู่ระบบหรือติดต่อเซิร์ฟเวอร์ authetication ที่ใช้ร่วมกันเพื่อให้แม้ใช้คีย์เดียวกันสำหรับผู้เล่นที่แตกต่างกันบนเซิร์ฟเวอร์ที่แตกต่างกันในเวลาเดียวกันจะล้มเหลว คุณอาจต้องการค้นหารูปแบบที่น่าสงสัยในการใช้คีย์และหากคุณพิจารณาว่าคีย์รั่วไหลให้เพิ่มเข้าไปในรายการคีย์ที่ถูกห้าม
สำหรับส่วนที่สองวิธีหนึ่งคือการรักษาฐานข้อมูลของคีย์ที่ออกให้ที่ถูกต้องทั้งหมด ตราบใดที่คีย์นั้นมีความยาวเพียงพอ (เช่น 128 บิตขึ้นไป) และเลือกแบบสุ่ม (โดยใช้ RNG ที่ปลอดภัย) โอกาสของทุกคนที่จัดการเพื่อเดาคีย์ที่ถูกต้องนั้นเป็นศูนย์ (แม้แต่ปุ่มที่สั้นกว่าก็ยังสามารถปลอดภัยได้หากคุณใช้การ จำกัด อัตราการพยายามล็อกอินล้มเหลวเพื่อหยุดความพยายามในการค้นหาคีย์ที่ถูกต้องโดยใช้กำลังดุร้าย)
หรือคุณสามารถสร้างคีย์ได้โดยใช้ตัวระบุที่ไม่ซ้ำกันและเพิ่มรหัสการตรวจสอบข้อความ (เช่นHMAC ) ซึ่งคำนวณโดยใช้รหัสลับหลักลงไป อีกครั้งตราบใดที่ MAC นั้นยาวพออัตราต่อรองของใครก็ตามที่ไม่ทราบว่ามาสเตอร์คีย์นั้นสามารถเดา MAC ที่ถูกต้องสำหรับ ID ใด ๆ นั้นจะไม่มีความสำคัญ ข้อดีอย่างหนึ่งของวิธีนี้นอกเหนือจากการลบความต้องการฐานข้อมูลคีย์คือตัวระบุสามารถเป็นสตริงที่ไม่ซ้ำกันและสามารถเข้ารหัสข้อมูลเกี่ยวกับไคลเอนต์ที่คีย์ออก
ปัญหาอย่างหนึ่งของการใช้ MAC คือเซิร์ฟเวอร์เกมอย่างเป็นทางการ (หรืออย่างน้อยเซิร์ฟเวอร์การตรวจสอบความถูกต้อง) จำเป็นต้องรู้รหัสหลักเพื่อตรวจสอบ MAC ซึ่งหมายความว่าหากเซิร์ฟเวอร์ถูกแฮ็กคีย์หลักอาจถูกรั่วไหล วิธีหนึ่งในการลดความเสี่ยงนี้คือการคำนวณ MACs จำนวนมากสำหรับแต่ละ ID โดยใช้คีย์หลักที่แตกต่างกัน แต่เก็บเฉพาะหนึ่งคีย์หลักบนเซิร์ฟเวอร์เกม ด้วยวิธีนี้หากคีย์หลักนั้นรั่วไหลและใช้สร้างรหัสปลอมคุณสามารถเพิกถอนและเปลี่ยนเป็นคีย์หลักอื่นได้ หรือคุณสามารถแทนที่ MAC ด้วยลายเซ็นดิจิทัลซึ่งสามารถตรวจสอบได้โดยใช้เพียงครึ่งสาธารณะของคีย์หลัก
สำหรับส่วนที่สามวิธีหนึ่งคือตรวจสอบให้แน่ใจว่าลูกค้าจะไม่ส่งกุญแจไปให้ใครโดยไม่ตรวจสอบว่าผู้รับเป็นเซิร์ฟเวอร์ที่เป็นทางการที่ถูกกฎหมายจริงๆ ตัวอย่างเช่นคุณสามารถใช้SSL / TLS (หรือDTLS ) สำหรับกระบวนการเข้าสู่ระบบออกใบรับรองที่กำหนดเองสำหรับเซิร์ฟเวอร์เกมของคุณและมีใบรับรองความน่าเชื่อถือของลูกค้าที่ออกโดยคุณเท่านั้น สะดวกในการใช้ TLS จะช่วยปกป้องคีย์ไคลเอ็นต์ (และข้อมูลการตรวจสอบความถูกต้องอื่น ๆ ) จากผู้ดักฟังเช่นบน WLAN สาธารณะ
น่าเสียดายที่วิธีการนี้จะไม่อนุญาตให้เซิร์ฟเวอร์บุคคลที่สามยืนยันรหัสลูกค้าแม้ว่าพวกเขาต้องการ คุณสามารถหลีกเลี่ยงปัญหานี้ได้โดยการตั้งค่าเซิร์ฟเวอร์รับรองความถูกต้องอย่างเป็นทางการที่เซิร์ฟเวอร์เกมของบุคคลที่สามสามารถใช้งานได้เช่นโดยให้ลูกค้าลงชื่อเข้าใช้เซิร์ฟเวอร์การตรวจสอบความถูกต้องและรับโทเค็นครั้งเดียวแบบสุ่ม เซิร์ฟเวอร์เกม (ซึ่งจะส่งโทเค็นไปยังเซิร์ฟเวอร์การตรวจสอบความถูกต้องเพื่อตรวจสอบ)
อีกวิธีหนึ่งคือคุณสามารถออกใบรับรองลูกค้าจริงหรืออะไรทำนองนั้นกับลูกค้าของคุณ คุณสามารถใช้โปรโตคอลที่มีอยู่ (เช่น TLS) ที่รองรับการตรวจสอบรับรองลูกค้า (แนะนำ) หรือใช้งานของคุณเองเช่นนี้:
- ใบรับรองไคลเอ็นต์ประกอบด้วยสตริง ID โดยพลการคู่คีย์สาธารณะ / ส่วนตัวและลายเซ็นดิจิทัลของ ID และคีย์สาธารณะโดยใช้คีย์หลัก
- ในการเข้าสู่ระบบลูกค้าจะส่งรหัสประชาชนกุญแจและลายเซ็นของพวกเขา เซิร์ฟเวอร์ตอบกลับด้วยสตริงการท้าทายที่ไม่ซ้ำกัน (โดยเฉพาะอย่างยิ่งรวมถึง ID เซิร์ฟเวอร์และการประทับเวลาที่ลูกค้าควรตรวจสอบ) ซึ่งลูกค้าลงนามด้วยรหัสส่วนตัว (เพื่อพิสูจน์ว่าพวกเขารู้ว่ากุญแจ) และส่งลายเซ็นไปยังเซิร์ฟเวอร์
- เซิร์ฟเวอร์ตรวจสอบทั้งลายเซ็นเพื่อพิสูจน์ว่า ID + พับลิคคีย์เป็นรหัสไคลเอนต์ที่ถูกต้อง (ตั้งแต่พวกเขาเซ็นชื่อด้วยมาสเตอร์คีย์) และคีย์ไคลเอ็นต์นั้นเป็นของลูกค้าจริง ๆ (เนื่องจากไคลเอนต์สามารถเซ็นชื สำคัญ).
(โปรโตคอลนี้สามารถทำให้ง่ายขึ้นอีกโดยให้ไคลเอนต์สร้าง "ความท้าทาย" ประกอบด้วย ID เซิร์ฟเวอร์และการประทับเวลาและลงนามแน่นอนแล้วเซิร์ฟเวอร์ต้องตรวจสอบว่า ID และการประทับเวลานั้นถูกต้องแล้วโปรดทราบด้วยว่า โปรโตคอลอย่างง่ายนี้จะไม่หยุดผู้โจมตีคนกลางที่จะสามารถขโมยเซสชันของไคลเอ็นต์แม้ว่าจะป้องกันไม่ให้พวกเขาได้รับรหัสส่วนตัวของลูกค้าที่จำเป็นสำหรับการเข้าสู่ระบบในอนาคต)