Score:2

ฟังก์ชันแฮชใดดีพอสำหรับรหัสเซสชัน

ธง br

พื้นหลัง

ฉันกำลังสร้างตัวย่อ URL และ URL ที่จะย่ออาจมี รหัสเซสชัน.

เพื่อให้ตัวย่อ URL นั้นไม่กระทบต่อความปลอดภัยของ SessionId ฉันต้องใช้กลยุทธ์การย่อที่เป็นไปตามข้อกำหนดเดียวกันกับ SessionId

OWASP ระบุว่า:

  • ความยาว ID เซสชันต้องมีความยาวอย่างน้อย 128 บิต (16 ไบต์) ที่นี่
  • ต้องระบุค่ารหัสเซสชันเป็นอย่างน้อย 64 บิต ของเอนโทรปี ที่นี่

สิ่งที่คิดจะทำ

  • มีที่เก็บคีย์-ค่า โดยค่าคือ URL แบบยาว (ไม่ย่อ) และคีย์คือคอมโพเนนต์ URL แบบสั้น
  • เมื่อผู้ใช้นำทางไปยัง URL แบบย่อ URL แบบยาวจะถูกค้นหาในที่เก็บคีย์-ค่า และส่งกลับไปยังผู้ใช้ซึ่งจะถูกเปลี่ยนเส้นทาง

ดังนั้นกุญแจจะต้องมีอย่างน้อย 128 บิต (16 ไบต์) ยาวและให้อย่างน้อย 64 บิต ของเอนโทรปีเพื่อไม่ให้ SessionId เสียหาย

หากคีย์เป็นแฮชของค่า ฉันสามารถรับประกันความยาวของคีย์และทราบค่าเอนโทรปี (ขึ้นอยู่กับอัลกอริทึมการแฮชที่ใช้)

แต่ฉันควรใช้อัลกอริทึมการแฮชแบบใด

ตัวอย่างเช่น ความยาวไดเจสต์ MD5 คือ 128 บิตพอดี แต่ฉันไม่รู้ว่าค่าเอนโทรปีขั้นต่ำคืออะไร

คำถาม

อัลกอริทึมการแฮชข้อใดสร้างการย่อยอย่างน้อย 128 บิต โดยมีเอนโทรปีอย่างน้อย 64 บิต

(โพสต์ x จาก StackOverflow: https://stackoverflow.com/q/71224441/6517320)

kelalaka avatar
in flag
คุณช่วยรักษาสำเนาคำถามของคุณไว้หนึ่งชุดได้ไหม โปรดดู [การโพสต์คำถามข้ามไซต์ใน Stack Exchange หลายไซต์ได้รับอนุญาตหรือไม่ หากคำถามอยู่ในหัวข้อสำหรับแต่ละไซต์] (https://meta.stackexchange.com/q/64068/403350) เพื่อดูรายละเอียด
kelalaka avatar
in flag
โปรดทราบว่าเอนโทรปีไม่ใช่คุณสมบัติของค่า/ข้อมูล แต่เป็นคุณสมบัติของแหล่งที่มารับขนาด 64 บิตแบบสุ่มสม่ำเสมอและแฮชและตัดทอนเป็น 128 บิต ใช้ BLAKE2 เป็นแฮชการเข้ารหัสที่เร็วที่สุด แม้ว่าคุณไม่จำเป็นต้อง...
Score:5
ธง cn

คำตอบสั้นๆ สำหรับคำถามแฮชของคุณคือ "ใช้ SHA-256" นั่นคือคำตอบสำหรับปัญหาการแฮชที่ปลอดภัยเกือบทุกข้อ เว้นแต่คำตอบคือ "ใช้ SHA-512" หากคุณต้องการแฮช 128 บิต คุณสามารถตัดทอน SHA-256 (ใช้ 128 บิตแรกหรือ 128 บิตสุดท้าย) บิตทั้งหมดใน SHA-256 เป็นอิสระจากกัน ดังนั้นคุณจึงสามารถแยก 128 บิตเป็นแฮชได้

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

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

ด้วยการออกแบบของคุณ ผู้โจมตีไม่สามารถค้นหาแบบออฟไลน์ได้ พวกเขาต้องติดต่อเซิร์ฟเวอร์ของคุณ สมมติว่าคุณให้บริการได้ 1,000 คำขอ/วินาที และคุณปรับขนาดพื้นที่คีย์ทั้งหมดให้ใหญ่กว่าจำนวน URL ที่วางแผนไว้ถึงล้านล้านเท่า ผู้โจมตีจะใช้เวลาประมาณ 15,000 ปี (ประมาณ 1/2 ของพื้นที่ที่ค้นหา) เพื่อค้นหา URL เดียว หากพวกเขาสามารถใช้แบนด์วิดท์ทั้งหมดของคุณที่มีอยู่ (ซึ่งฉันคาดว่าคุณอาจสังเกตเห็น....) ด้วยการจำกัดอัตราเพียงเล็กน้อยต่อที่อยู่ IP คุณสามารถทำให้การโจมตีนี้ซับซ้อนขึ้นอย่างมาก

จากที่กล่าวมา หากคุณต้องการจัดเก็บ URL พันล้านรายการในระบบของคุณ คุณต้องมีคีย์สเปซดังนี้:

log2(1 พันล้าน URL * ตัวคูณ 1 ล้านล้าน) = 80 บิต

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

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

IMO ไม่จำเป็นต้องแฮช แต่ถ้าคุณต้องการ ให้ใช้ SHA-256 ตัดให้เหลือจำนวนบิตเท่าที่คุณต้องการ

Ivan Rubinson avatar
br flag
สิ่งนี้รับประกันเอนโทรปีอย่างน้อย 64 บิตได้อย่างไร
cn flag
ขึ้นอยู่กับ PRNG ของคุณ บนระบบ Linux หากคุณใช้ /dev/random ฉันเชื่อว่ามันจะบล็อกหากระบบมีค่าเอนโทรปีต่ำกว่า 160 บิต ดังนั้นคุณควรจะโอเคกับระบบประเภทนั้น ฉันคาดว่าระบบใดๆ ที่คุณใช้ PRNG ที่เข้ารหัสจะเกิน 64 บิตอย่างมากสำหรับทุกค่า แต่คุณจะต้องตรวจสอบเอกสารของคุณเพื่อความแน่ใจ ตัวอย่างเช่น ในบางระบบ (แต่ไม่ใช่ทั้งหมด) /dev/urandom จะส่งคืนค่าเอนโทรปีต่ำ
cn flag
แต่ไม่มีฟังก์ชันแฮชใดที่สามารถเพิ่มเอนโทรปีได้ และหากฟังก์ชันนี้ป้องกันการชนกันของพื้นที่ที่เป็นปัญหา ก็จะลดเอนโทรปีไม่ได้ (อย่างมีประสิทธิผล) เอนโทรปีจาก SessionId ดั้งเดิมจะถูกรักษาไว้โดยแฮชการเข้ารหัสใดๆ หากเดิมมีน้อยกว่า 64 บิต แฮชก็จะเป็นเช่นนั้น และหากมีมากกว่า 64 บิต แฮชก็จะเช่นกัน (ลบเล็กน้อย) ในการเพิ่มเอนโทรปี คุณต้องเพิ่มเกลือแบบสุ่ม ซึ่งหมายความว่าคุณเชื่อมโยงกับเอนโทรปีของ PRNG ของคุณ (เหมือนกับการใช้คีย์สุ่ม) https://crypto.stackexchange.com/questions/12505/what-happens-to-entropy-after-hashing
Ivan Rubinson avatar
br flag
ดังนั้น เอนโทรปีของแฮช = เอนโทรปีของข้อความธรรมดา ดังนั้นเพื่อให้แน่ใจว่าเอนโทรปีเพียงพอ ข้อความธรรมดาจำเป็นต้องมีเอนโทรปีสูง URL แบบยาวมีเอนโทรปีต่ำ ตรงข้ามกับสตริงสุ่มเทียมที่เข้ารหัสแบบไบต์ ซึ่งเป็นเหตุผลที่คุณแนะนำคีย์ไม่ให้เป็นแฮชของ URL แบบยาว
cn flag
ปิด แต่เอนโทรปีของแฮชไม่เคยมากกว่าเอนโทรปีของข้อความธรรมดา แฮชที่ทนต่อการชนเพียงแค่ลดเอนโทรปีให้น้อยลง (โดยทั่วไปจะเป็นจำนวนที่ไม่สำคัญ) ความคิดเห็นที่เหลือของคุณถูกต้อง
Ivan Rubinson avatar
br flag
ขออภัยสัญกรณ์ที่สับสน ถ้า `A = B` ก็เป็นไปไม่ได้สำหรับ `A > B` เนื่องจากการแฮชไม่สามารถเพิ่มเอนโทรปีได้ แต่สามารถลดเอนโทรปีได้ เราจึงไม่ได้รับผลประโยชน์จากการแฮช แต่จะสูญเสียเท่านั้น
SAI Peregrinus avatar
si flag
"ในระบบ Linux หากคุณใช้ /dev/random ฉันเชื่อว่ามันจะบล็อกหากระบบลดลงต่ำกว่า 160 บิตของเอนโทรปีที่มีอยู่" นั่นไม่เป็นความจริงมาระยะหนึ่งแล้ว ไม่ว่ามันจะสำคัญ แต่มันจะบล็อกเฉพาะในการบู๊ตก่อนเวลาและจะไม่เกิดขึ้นอีก เอนโทรปีไม่ได้ "หมด" ดังนั้นการบล็อกหลังจากการเพาะไม่เคยช่วยอะไรเลย
cn flag
ขอบคุณ @SAIPeregrinus ฉันไม่ได้เป็น sysadmin สำหรับ Linux มานานแล้ว :D คุณมีลิงค์เกี่ยวกับสถานการณ์ปัจจุบันใน Linux เพื่อให้ฉันได้รับการศึกษาที่ดีขึ้นหรือไม่? (สมองการเข้ารหัสของฉันเข้าใจอย่างถ่องแท้ว่าคุณหมายถึงอะไร ฉันแค่ต้องการให้ฝ่ายดูแลระบบของฉันเข้าใจว่าเกิดอะไรขึ้นในทางปฏิบัติ)
kelalaka avatar
in flag
[มีปัญหาอะไรบ้างขณะใช้ /dev/urandom ของ Linux ในการสร้างคีย์การเข้ารหัส](https://crypto.stackexchange.com/q/85533/18298)
SAI Peregrinus avatar
si flag
ดู [บทความ LWN นี้](https://lwn.net/SubscriberLink/884875/650dde925be055a1/) ในแพตช์ที่เสนอเพื่อรวมพฤติกรรมของ /dev/random และ /dev/urandom และ getrandom(flags=0)
Ivan Rubinson avatar
br flag
มีการพูดคุยกันมากมายเกี่ยวกับวิธีที่ Linux จัดการกับ CSPRNG แล้ววินโดวส์ล่ะ?

โพสต์คำตอบ

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