การรับรองความถูกต้องของไดรฟ์คืออะไร?


101

Digest Authentication แตกต่างจาก Basic Authentication อย่างไรนอกเหนือจากการส่งหนังสือรับรองเป็นข้อความธรรมดา


1
คำอธิบายที่ยอดเยี่ยมโดย @Gumbo ที่นี่: stackoverflow.com/a/5288679/591487
inorganik

2
สิ่งที่คุณไม่ควรใช้ ไม่ป้องกันรหัสผ่านระหว่างการส่งและต้องการให้เซิร์ฟเวอร์จัดเก็บรหัสผ่านแบบธรรมดา
CodesInChaos

2
ไดเจสต์ให้ความปลอดภัยในการส่งผ่านที่ดีกว่าการตรวจสอบสิทธิ์ขั้นพื้นฐานสำหรับการรับส่งข้อมูลที่ไม่ได้เข้ารหัสแต่ก็อ่อนแอ ปลอดภัยกว่ามากที่จะใช้การตรวจสอบสิทธิ์ขั้นพื้นฐานร่วมกับ SSL / TLS แทนเนื่องจากวิธีนี้คุณสามารถเข้ารหัสรหัสผ่านบนเซิร์ฟเวอร์ได้
rustyx

คำตอบ:


179

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

เซิร์ฟเวอร์ให้หมายเลขใช้งานครั้งเดียว (nonce) ไคลเอ็นต์ซึ่งรวมเข้ากับชื่อผู้ใช้ขอบเขตรหัสผ่านและคำขอ URI ไคลเอนต์รันฟิลด์เหล่านั้นทั้งหมดผ่านวิธีการแฮช MD5 เพื่อสร้างคีย์แฮช

จะส่งคีย์แฮชนี้ไปยังเซิร์ฟเวอร์พร้อมกับชื่อผู้ใช้และขอบเขตเพื่อพยายามตรวจสอบสิทธิ์

ฝั่งเซิร์ฟเวอร์ใช้วิธีการเดียวกันในการสร้างแฮชคีย์เท่านั้นแทนที่จะใช้รหัสผ่านที่พิมพ์ลงในเบราว์เซอร์เซิร์ฟเวอร์จะค้นหารหัสผ่านที่คาดไว้สำหรับผู้ใช้จากฐานข้อมูลผู้ใช้ ค้นหารหัสผ่านที่จัดเก็บไว้สำหรับชื่อผู้ใช้นี้ทำงานผ่านอัลกอริทึมเดียวกันและเปรียบเทียบกับสิ่งที่ไคลเอ็นต์ส่งมา หากตรงกันก็จะได้รับสิทธิ์การเข้าถึงมิฉะนั้นจะสามารถส่ง 401 Unauthorized กลับมาได้ (ไม่มีการเข้าสู่ระบบหรือการเข้าสู่ระบบที่ล้มเหลว) หรือ 403 Forbidden (การเข้าถึงถูกปฏิเสธ)

การตรวจสอบ Digest เป็นมาตรฐานใน RFC2617 มีภาพรวมที่ดีใน Wikipedia :

คุณสามารถคิดได้ดังนี้:

  1. ลูกค้าทำการร้องขอ
  2. ไคลเอนต์ได้รับ nonce กลับจากเซิร์ฟเวอร์และคำขอการรับรองความถูกต้อง 401
  3. ไคลเอนต์ส่งกลับอาร์เรย์การตอบกลับต่อไปนี้ (ชื่อผู้ใช้, ขอบเขต, create_md5_key (nonce, ชื่อผู้ใช้, ขอบเขต, URI, password_given_by_user_to_browser)) (ใช่มันง่ายมาก)
  4. เซิร์ฟเวอร์รับชื่อผู้ใช้และขอบเขต (รวมทั้งรู้ URI ที่ไคลเอ็นต์ร้องขอ) และค้นหารหัสผ่านสำหรับชื่อผู้ใช้นั้น จากนั้นจะไปและสร้างเวอร์ชันของตัวเองของ create_md5_key (nonce, username, realm, URI, password_I_have_for_this_user_in_my_db)
  5. จะเปรียบเทียบเอาต์พุตของ create_md5 () ที่ได้รับกับไคลเอ็นต์ที่ส่งหากตรงกับไคลเอ็นต์ที่ส่งรหัสผ่านที่ถูกต้อง หากไม่ตรงกับรหัสผ่านที่ส่งถือว่าผิด

คำอธิบายที่ดี ชื่อผู้ใช้ & pwd สำหรับผู้ใช้ windows หรือไม่? สร้างจากที่ไหน?
SoftwareGeek

เป็นสิ่งที่ผู้ใช้พิมพ์ลงในเบราว์เซอร์ รหัสผ่านต้องตรงกับสิ่งที่เซิร์ฟเวอร์จัดเก็บไว้สำหรับรหัสผ่านสำหรับผู้ใช้นั้น มีแนวโน้มที่จะไม่ใช่สิ่งที่เฉพาะเจาะจงสำหรับเว็บแอปพลิเคชันนั้นไม่ใช่รหัสผ่าน Windows ของคุณ มากขึ้นอยู่กับวิธีการรวมโปรแกรมประยุกต์บนเว็บ
Ian C.

14
คำตอบนี้มีอายุ 6 ปีแล้ว แต่ตอนนี้ฉันเดาว่าระบบที่ตระหนักถึงความปลอดภัยทั้งหมดจะจัดเก็บรหัสผ่านในรูปแบบแฮชเค็ม ไม่มีและไม่ควรมีวิธีการใด ๆ ในการขอรับรหัสผ่านเดิมจากฐานข้อมูลทำให้ไม่สามารถทำการอนุญาตไดเจสต์ได้
Ramon de Klein

3
หากการย่อยแฮชของชื่อผู้ใช้และรหัสผ่านถูกเก็บไว้ในฐานข้อมูลแทนที่จะเป็นรหัสผ่านธรรมดาก็ยังสามารถใช้การตรวจสอบการย่อยอาหารได้ @RamondeKlein
karakays

1
@BlueBockser ฉันคิดว่าคาราเคย์หมายความว่าแทนที่จะใช้รหัสผ่านธรรมดาแฮชที่เกิดจากการรวมทั้งชื่อผู้ใช้และรหัสผ่านควรถูกเก็บไว้ในเซิร์ฟเวอร์เมื่อสมัครและคำนวณในฝั่งไคลเอ็นต์ก่อนที่จะตรวจสอบสิทธิ์ นอกจากนี้ยังสามารถทำได้โดยใช้เพียงแฮชรหัสผ่าน
logo_writer

14

แฮชของข้อมูลประจำตัวจะถูกส่งผ่านสาย

HA1 = MD5(username:realm:password)

Wikipedia มีบทความที่ยอดเยี่ยมในหัวข้อนี้


จากไคลเอนต์ไปยังเซิร์ฟเวอร์? คุณช่วยระบุขั้นตอนสำหรับการโต้ตอบได้ไหม บทความ Wikipedia ดี แต่ฉันต้องการคำอธิบายหรือตัวอย่างที่ดีกว่านี้
SoftwareGeek

ใช่ไคลเอ็นต์สร้างค่าแฮชและส่งไปยังเซิร์ฟเวอร์ บทความ Wikipedia อธิบายโปรโตคอลโดยละเอียดฉันขอแนะนำให้คุณอ้างอิงสำหรับข้อมูลเพิ่มเติม
Philip Fourie

1

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


นี่คือคำอธิบายสำหรับการตรวจสอบความถูกต้องของไดเจสต์โดยที่รหัสผ่านจะไม่ถูกส่งเป็นข้อความธรรมดา (ซึ่งเป็นกรณีของการตรวจสอบสิทธิ์ขั้นพื้นฐาน)
Erik Oppedijk
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.