รูปแบบการใช้งานการเข้ารหัสที่ผิดพลาดที่พบบ่อย

โหมดสมุดรหัสอิเล็กทรอนิกส์ (ECB) เข้ารหัสแต่ละบล็อกอย่างอิสระด้วยคีย์เดียวกัน บล็อกข้อความต้นฉบับที่เหมือนกันจะสร้างบล็อกข้อความเข้ารหัสที่เหมือนกัน การสาธิตแบบคลาสสิกคือ "เพนกวิน ECB" โดยการเข้ารหัสภาพบิตแมปด้วย ECB จะคงโครงสร้างระดับบล็อกของภาพไว้ ทำให้มองเห็นเค้าโครงของเพนกวินในข้อความเข้ารหัสได้อย่างชัดเจน โหมด ECB ไม่มีความปลอดภัยเชิงความหมาย และไม่ควรใช้เพื่อวัตถุประสงค์การเข้ารหัสจริงใด ๆ

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

MD5 ถูกทำลายด้านการชนกันของแฮชมาตั้งแต่ปี 2004 การสร้างไฟล์สองไฟล์ที่มีแฮช MD5 เดียวกันสามารถทำได้ง่ายในเชิงการคำนวณ การโจมตีการชนกันของ SHA-1 ได้รับการสาธิตในทางปฏิบัติผ่านการโจมตี SHAttered ของ Google ในปี 2017 ซึ่งสร้างไฟล์ PDF สองไฟล์ที่มีแฮช SHA-1 เดียวกัน ไม่ควรใช้ทั้งสองอย่างเพื่อวัตถุประสงค์ด้านความปลอดภัยใด ๆ ไม่ว่าจะเป็นลายเซ็นดิจิทัล ความถูกต้องครบถ้วนของเนื้อหา การจัดเก็บรหัสผ่าน หรือ HMAC ควรใช้ SHA-256, SHA-3 หรือ BLAKE2 สำหรับระบบสมัยใหม่

การใช้ time() หรือค่าที่คาดเดาได้อื่น ๆ เพื่อกำหนดค่าเริ่มต้นให้ตัวสร้างเลขสุ่มเทียมเป็นช่องโหว่ร้ายแรง เมื่อใช้ผลลัพธ์ PRNG เพื่อวัตถุประสงค์ด้านความปลอดภัย ผู้โจมตีที่ทราบเวลาคร่าว ๆ ที่สร้างคีย์สามารถไล่เดาพื้นที่ค่าเริ่มต้นได้ ซึ่งก็คือค่าประทับเวลาที่เป็นไปได้ทั้งหมดในช่วงเวลาสั้น ๆ เพื่อกู้คืนคีย์ ตัวอย่างคลาสสิกคือ Netscape รุ่นแรก ๆ ใช้เวลาและรหัสกระบวนการในการกำหนดค่าเริ่มต้นสำหรับการสร้างคีย์ SSL ซึ่งทั้งสองอย่างผู้โจมตีบนเครื่องเดียวกันสามารถสังเกตได้

rand() ใน C, java.util.Random และมอดูล random ของ Python ใช้ตัวสร้างแบบเชิงเส้นที่มีการทบค่า หรือ Mersenne Twister ซึ่งออกแบบมาเพื่อคุณภาพทางสถิติในการจำลอง ไม่ใช่เพื่อความปลอดภัย ผู้โจมตีที่สังเกตผลลัพธ์จากตัวสร้างเหล่านี้ได้มากพอสามารถสร้างสถานะภายในขึ้นใหม่และคาดเดาผลลัพธ์ในอนาคตทั้งหมดได้ สำหรับวัตถุประสงค์ด้านความปลอดภัย ให้ใช้ CSPRNG ที่ระบบปฏิบัติการจัดให้ ได้แก่ secrets.token_bytes() ใน Python, crypto.randomBytes() ใน Node.js หรือ /dev/urandom บน Linux

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

การฝังคีย์เข้ารหัสหรือเวกเตอร์เริ่มต้นไว้แบบตายตัวในซอร์สโค้ดเป็นช่องโหว่ร้ายแรง ซอร์สโค้ดมักถูกบันทึกไว้ในที่เก็บข้อมูลควบคุมเวอร์ชัน ซึ่งบางแห่งเปิดเผยต่อสาธารณะ แม้จะเป็นที่เก็บข้อมูลส่วนตัว ผู้ใดก็ตามที่เข้าถึงโค้ดได้ก็มีคีย์นั้น คีย์ที่ฝังไว้แบบตายตัวทำให้ทุกอินสแตนซ์ใช้คีย์เดียวกัน และการเปลี่ยนคีย์จำเป็นต้องปรับใช้ระบบใหม่ คีย์ต้องจัดเก็บไว้ในตัวแปรสภาพแวดล้อม ระบบจัดการข้อมูลลับ (HashiCorp Vault, AWS Secrets Manager) หรือโมดูลความปลอดภัยฮาร์ดแวร์

การใช้เวกเตอร์เริ่มต้นเดียวกันในการเข้ารหัสหลายครั้งด้วยคีย์เดียวกันสร้างช่องโหว่ร้ายแรง ในโหมด CTR การใช้ IV ซ้ำจะสร้างกระแสกุญแจเดียวกัน ทำให้กู้คืนข้อความต้นฉบับได้ด้วย XOR ในโหมด CBC การใช้ IV ซ้ำทำให้ผู้โจมตีตรวจจับได้ว่าเมื่อใดที่ข้อความสองรายการเริ่มต้นด้วยบล็อกข้อความต้นฉบับเดียวกัน ใน GCM การใช้ค่าที่ใช้ครั้งเดียว (IV) ซ้ำมีผลร้ายแรงอย่างยิ่ง (ดูบทเรียนเรื่องการใช้ค่าที่ใช้ครั้งเดียวซ้ำ) ควรสร้าง IV แบบสุ่มใหม่ทุกครั้งที่เข้ารหัส และเติมไว้ด้านหน้าข้อความเข้ารหัสเพื่อจัดเก็บไว้พร้อมบริบทการถอดรหัส

การจัดเก็บรหัสผ่านที่แฮชด้วย MD5, SHA-256 หรือแฮชการเข้ารหัสแบบเร็วอื่นใดไม่เพียงพอ หน่วยประมวลผลกราฟิกสมัยใหม่สามารถคำนวณแฮช SHA-256 ได้หลายพันล้านค่าต่อวินาที ทำให้การโจมตีแบบไล่เดาแบบออฟไลน์ต่อฐานข้อมูลแฮชที่ถูกขโมยทำได้อย่างรวดเร็ว การแฮชรหัสผ่านจำเป็นต้องใช้ฟังก์ชันที่สร้างมาโดยเฉพาะ ซึ่งทำงานช้าและใช้หน่วยความจำมาก ได้แก่ bcrypt, scrypt หรือ Argon2id ฟังก์ชันเหล่านี้ออกแบบมาเพื่อทำให้การไล่เดามีต้นทุนสูง แม้ใช้ฮาร์ดแวร์เฉพาะทาง จึงทำให้การโจมตีแบบออฟไลน์ทำได้ยากในทางคำนวณ

การปิดใช้การตรวจสอบใบรับรอง SSL/TLS (การตั้งค่า ssl.CERT_NONE ใน Python การส่ง -k ให้ curl หรือการตั้งค่า trustAllCerts=true ใน Android) จะขจัดการป้องกันการโจมตีแบบคนกลาง ผู้โจมตีสามารถนำเสนอใบรับรองใด ๆ และดักจับการสื่อสารทั้งหมดได้ แนวปฏิบัตินี้พบได้ในการพัฒนาเพื่อหลีกเลี่ยงข้อผิดพลาดจากใบรับรองที่ลงนามด้วยตนเอง แต่บ่อยครั้งกลับคงอยู่จนถึงระบบที่ใช้งานจริง ควรใช้การตรวจสอบใบรับรองที่ถูกต้องเสมอ และแก้ไขปัญหาใบรับรองต้นเหตุอย่างถูกวิธี

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

รูปแบบการใช้งานผิดที่พบบ่อยซึ่งควรหลีกเลี่ยง: ห้ามใช้โหมด ECB (เพราะทำให้รูปแบบของบล็อกรั่วไหล) ห้ามเขียนโครงสร้างพื้นฐานของการเข้ารหัสลับเอง ห้ามใช้ MD5 และ SHA-1 เพื่อความปลอดภัย กำหนดค่าเริ่มต้นให้ PRNG ด้วย CSPRNG ไม่ใช่ time() ใช้ CSPRNG สำหรับการสุ่มที่เกี่ยวข้องกับความปลอดภัยทั้งหมด ตรวจสอบสิทธิ์ข้อมูลที่เข้ารหัสเสมอ (AEAD) ห้ามฝังคีย์หรือ IV ไว้ตายตัว สร้าง IV ใหม่ทุกครั้งที่เข้ารหัส ใช้ Argon2id กับรหัสผ่านแทนแฮชที่คำนวณได้รวดเร็ว ตรวจสอบใบรับรอง TLS เสมอ และตรวจสอบค่าที่ส่งกลับจากการดำเนินการเข้ารหัสลับทุกค่า