Score:1

ผู้โจมตีสามารถขโมยข้อมูลจากตารางที่เข้ารหัส AES โดยไม่ทราบรหัสได้หรือไม่

ธง in

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

สมมติว่าตารางถูกเข้ารหัสด้วยคีย์เดียวกัน แต่ IV ต่างกัน:

  1. Attacker ลงทะเบียนสำหรับบัญชีใหม่ในแอปพลิเคชันตามปกติ
  2. แอปพลิเคชันสร้างบัญชีและแทรกแถวใหม่ (แถวที่ 2 ในตารางด้านล่าง)
  3. ผู้โจมตีพบช่องโหว่ในแอปพลิเคชันเพื่อเรียกใช้ SQL Injection
  4. ด้วยการฉีด SQL ผู้โจมตีจะแทนที่รหัสของแถวด้วยค่าของเหยื่อ เช่น. aes_cipher_2 -> aes_cipher_1 และ iv_2 -> iv_1
  5. ผู้โจมตีลงชื่อเข้าใช้บัญชีของเขาเอง
  6. ผู้โจมตีไปที่หน้าโปรไฟล์ จากนั้นแอปพลิเคชันจะถอดรหัสข้อมูลของเหยื่อ (aes_cipher_1) และแสดงข้อความธรรมดาให้เขาเห็น
รหัส ชื่อผู้ใช้ ที่อยู่ IV
1 เหยื่อ aes_cipher_1 iv_1
2 ผู้โจมตี aes_cipher_2 iv_2
DannyNiu avatar
vu flag
ดีสำหรับการทดลองคิด แต่ควรแนะนำแนวทางปฏิบัติที่ดีที่สุดแก่ผู้อ่าน: ใช้คำสั่งที่เตรียมไว้และผูกตัวแปรในแบบสอบถาม SQL เพื่อหลีกเลี่ยงการฉีด เข้ารหัสฐานข้อมูลที่ระดับระบบไฟล์ การเข้ารหัสระดับตารางข้อมูลนั้นละเอียดเกินกว่าจะมีประสิทธิภาพ
DannyNiu avatar
vu flag
ตอนนี้กลับไปที่คำถาม คุณกำลังมองหาการบรรเทา (ซึ่งฉันได้ให้ไว้ในความคิดเห็นที่ 1) หรือไม่? หรือคุณต้องการบางอย่างที่ใช้งานได้จริง เช่น การสาธิตการโจมตี?
fgrieu avatar
ng flag
คำแนะนำของ DannyNiu นั้นดี โปรดทราบว่า «เข้ารหัสฐานข้อมูลที่ระดับระบบไฟล์» ไม่ได้ช่วยแก้ปัญหาของคำถาม การเข้ารหัสที่รับรองความถูกต้อง (AES-GCM ในลักษณะเดียวกัน) และการรวมฟิลด์ _ID_ และ _Username_ ในข้อมูลที่ผ่านการรับรองความถูกต้อง ไปในทิศทางนั้น แต่ท้ายที่สุด หากผู้โจมตีเข้ามาในระบบของคุณมากพอที่จะอ่าน เปลี่ยนแปลงฐานข้อมูลมากขึ้น หรือคุณต้องการการเข้ารหัสระดับระบบไฟล์ แสดงว่าคุณประสบปัญหาใหญ่หลวง วัตถุประสงค์หลักควรหลีกเลี่ยงสิ่งนั้น การเข้ารหัสฐานข้อมูลหรือระบบไฟล์ (ตรวจสอบความถูกต้อง) ควรเป็นมาตรการรักษาความปลอดภัย _extra_
in flag
@DannyNiu ยอมรับว่าข้อความที่เตรียมไว้สามารถป้องกันการโจมตีด้วยการฉีดได้ อย่างไรก็ตาม ฉันคิดว่ามาตรการนี้ล้มเหลวในสถานการณ์นี้ คุณช่วยแนะนำการลดหย่อนบางอย่างได้ไหม?
in flag
@fgrieu คุณหมายถึงการรวม ID / ชื่อผู้ใช้ในคีย์เข้ารหัสหรือไม่
kelalaka avatar
in flag
ใช่ [ข้อเสนอนี้เทียบกับฐานข้อมูลที่เข้ารหัสด้วย CryptDB](https://ieeexplore.ieee.org/abstract/document/7034869/) คุณอาจพบสคริปต์ SQL ที่นั่นด้วยซ้ำ คุณต้องมีความสมบูรณ์และการรับรองความถูกต้องเพื่อลด...
Score:3
ธง ng

ใช่ การโจมตีในคำถามสามารถทำงานได้ภายใต้สมมติฐานที่ระบุไว้ ไม่แนะนำให้เข้ารหัส AES-CTR ของช่องฐานข้อมูลด้วยเหตุผลนี้และอื่นๆ

กำลังใช้การบรรเทาบางส่วนที่เป็นไปได้ เข้ารหัสรับรองความถูกต้องตัวอย่างเช่น AES-GCM และรวมถึง รหัส และ ชื่อผู้ใช้ ฟิลด์ในข้อมูลที่รับรองความถูกต้อง ผลกระทบสุทธิคือข้อมูลที่เข้ารหัส (ในไฟล์ ที่อยู่ ฟิลด์) เปลี่ยนแปลงในทางใดทางหนึ่ง รวมทั้งแยกจากต้นฉบับ รหัส หรือ ชื่อผู้ใช้ หรือ IVจะล้มเหลวในการถอดรหัสด้วยความมั่นใจในการเข้ารหัส

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

การเข้ารหัสที่รับรองความถูกต้องให้การป้องกันที่ดีกว่าการรับคีย์ AES-CTR จากมาสเตอร์คีย์และ รหัส หรือ/และ ชื่อผู้ใช้: หากผู้ไม่หวังดีสามารถจัดการเพื่อเปลี่ยนแปลงข้อมูลที่เข้ารหัส CTR และสังเกตพฤติกรรมของระบบไอทีบางอย่างในข้อมูลที่ถอดรหัสได้ ก็ไม่ต้องกลัวว่าพวกเขาจะเรียนรู้บางอย่างเกี่ยวกับข้อมูล ตัวอย่างเช่น หากไบต์ '<' ในข้อมูลที่ถอดรหัสทำให้เกิดพฤติกรรมบางอย่างที่จดจำได้ ก็จะต้องใช้ความพยายาม 30 ครั้งต่ออักขระในการถอดรหัส เหมือนในภาพยนตร์ การเข้ารหัสที่รับรองความถูกต้องป้องกันสิ่งนี้ คีย์ที่ได้รับไม่ได้ป้องกัน

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

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

โพสต์คำตอบ

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