Digest และ Authentication พื้นฐานแตกต่างกันอย่างไร

DigestและBasicแตกต่างกันอย่างไร Authenticationอย่างไร

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

ในขณะที่การรับรองความถูกต้องเบื้องต้นใช้ไม่มีการเข้ารหัส base64 ที่ไม่มีการเข้ารหัส

ดังนั้นโดยทั่วไปควรใช้การรับรองความถูกต้องพื้นฐานเมื่อมีการระบุความปลอดภัยของเลเยอร์การขนส่งเช่น https

ดูRFC-2617สำหรับรายละเอียดเต็มไปด้วยเลือดทั้งหมด

การตรวจสอบสิทธิ์การเข้าถึง HTTP เบื้องต้น

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

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

ข้อดี:

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

จุดด้อย:

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

โดยสรุป - หากคุณมีการควบคุมลูกค้าหรือสามารถมั่นใจได้ว่าพวกเขาใช้ SSL, HTTP Basic เป็นตัวเลือกที่ดี ความช้าของ SSL สามารถถูกยกเลิกได้ด้วยความเร็วเพียงการร้องขอเพียงครั้งเดียว

ไวยากรณ์ของการพิสูจน์ตัวตนพื้นฐาน

Value = username:password
Encoded Value =  base64(Value)
Authorization Value = Basic <Encoded Value> 
//at last Authorization key/value map added to http header as follows
Authorization: <Authorization Value>

การตรวจสอบสิทธิ์ HTTP Digest Access การตรวจสอบสิทธิ์การเข้าถึง
Digest ใช้วิธีการแฮช (เช่นข้อมูลย่อยหมายถึงตัดเป็นชิ้นเล็ก ๆ ) เพื่อสร้างผลลัพธ์การเข้ารหัส การตรวจสอบสิทธิ์การเข้าถึง HTTP Digest เป็นรูปแบบการตรวจสอบที่ซับซ้อนมากขึ้นซึ่งทำงานดังนี้:

• ขั้นตอนที่ 1 : ไคลเอนต์ส่งการร้องขอไปยังเซิร์ฟเวอร์
• ขั้นตอนที่ 2 : เซิร์ฟเวอร์ตอบสนองด้วยรหัสพิเศษ (เรียกว่า aขณะปัจจุบันie n umber ใช้เพียงครั้งเดียว ), สตริงอื่นที่แสดงถึงขอบเขต (แฮช) และขอให้ลูกค้าตรวจสอบสิทธิ์
• ขั้นตอนที่ 3 : ไคลเอนต์ตอบสนองด้วย nonce นี้และรุ่นที่เข้ารหัสของชื่อผู้ใช้รหัสผ่านและขอบเขต (แฮ)
• ขั้นตอนที่ 4 : เซิร์ฟเวอร์ตอบสนองกับข้อมูลที่ร้องขอหากแฮชของไคลเอ็นต์ตรงกับแฮชของตนเองในชื่อผู้ใช้รหัสผ่านและขอบเขตหรือข้อผิดพลาดหากไม่ตรง

ข้อดี:

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

จุดด้อย:

• สำหรับการโทรทุกครั้งที่จำเป็นลูกค้าจะต้องทำ 2 ทำให้กระบวนการช้ากว่า HTTP Basic เล็กน้อย
• HTTP Digest เสี่ยงต่อการถูกโจมตีด้วยความปลอดภัยระดับกลางซึ่งหมายความว่ามันอาจถูกแฮ็ค
• HTTP Digest ป้องกันการใช้การเข้ารหัสรหัสผ่านที่คาดเดายากหมายความว่ารหัสผ่านที่เก็บไว้บนเซิร์ฟเวอร์อาจถูกแฮ็ก

โดยสรุป HTTP Digest นั้นมีความเสี่ยงต่อการโจมตีอย่างน้อยสองครั้งในขณะที่เซิร์ฟเวอร์ที่ใช้การเข้ารหัสที่รัดกุมสำหรับรหัสผ่านที่มี HTTP Basic ผ่าน SSL นั้นมีโอกาสน้อยที่จะแบ่งปันช่องโหว่เหล่านี้

หากคุณไม่สามารถควบคุมลูกค้าของคุณได้ แต่พวกเขาสามารถพยายามทำการรับรองความถูกต้องเบื้องต้นโดยไม่ใช้ SSL ซึ่งมีความปลอดภัยน้อยกว่า Digest

RFC 2069 ไวยากรณ์การตรวจสอบสิทธิ์การเข้าถึง Digest

Hash1=MD5(username:realm:password)
Hash2=MD5(method:digestURI)
response=MD5(Hash1:nonce:Hash2)

RFC 2617 ไวยากรณ์การตรวจสอบสิทธิ์การเข้าถึง Digest

Hash1=MD5(username:realm:password)
Hash2=MD5(method:digestURI)
response=MD5(Hash1:nonce:nonceCount:cnonce:qop:Hash2)
//some additional parameters added 

แหล่งที่มาและตัวอย่าง

ในบุรุษไปรษณีย์มีลักษณะดังนี้:

บันทึก:

• พื้นฐานและ Digest แผนการจะทุ่มเทให้กับการตรวจสอบโดยใช้ชื่อผู้ใช้และความลับ
• โครงการกุมภ์จะทุ่มเทให้กับการตรวจสอบโดยใช้สัญลักษณ์

ให้เราเห็นความแตกต่างระหว่างการตรวจสอบความถูกต้องHTTPสองอย่างโดยใช้Wireshark(เครื่องมือในการวิเคราะห์แพ็กเก็ตที่ส่งหรือรับ)

1. Http การรับรองความถูกต้องเบื้องต้น

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

นี่คือวิธีการส่งและรับแพ็กเก็ต:

ในแพคเก็ตแรกไคลเอนต์กรอกข้อมูลประจำตัวโดยใช้วิธีการPOSTที่ทรัพยากร - lab/webapp/basicauth. ในการคืนเซิร์ฟเวอร์ตอบกลับด้วยรหัสตอบกลับ http 200 okคือชื่อผู้ใช้: รหัสผ่านถูกต้อง

ตอนนี้ในAuthorizationส่วนหัวมันแสดงให้เห็นว่ามันเป็นการอนุญาตขั้นพื้นฐานตามด้วยสตริงสุ่มบางส่วนสตริงนี้เป็นข้อมูลประจำตัวที่เข้ารหัส (Base64)รุ่นadmin:aadd(รวมถึงลำไส้ใหญ่)

2. Http Digest Authentication (rfc 2069)

จนถึงตอนนี้เราได้เห็นแล้วว่าการรับรองความถูกต้องขั้นพื้นฐานส่งชื่อผู้ใช้: รหัสผ่านในแบบธรรมดาผ่านเครือข่าย แต่ Digest Auth ส่งHASHของรหัสผ่านโดยใช้อัลกอริทึมแฮช

นี่คือแพ็กเก็ตที่แสดงการร้องขอที่ทำโดยไคลเอนต์และการตอบสนองจากเซิร์ฟเวอร์

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

ในข้างต้นAuthorizationที่responseสตริงจะคำนวณโดยใช้ค่าของUsername, Realm, Password, http-method, URIและNonceตามที่แสดงในภาพ:

(รวม colons)

ดังนั้นเราจะเห็นได้ว่า Digest Authentication มีความปลอดภัยมากกว่าเนื่องจากเกี่ยวข้องกับ Hashing (การเข้ารหัส MD5) ดังนั้นเครื่องมือดมกลิ่นแพ็คเก็ตจึงไม่สามารถดมรหัสผ่านได้แม้ว่าใน Auth พื้นฐานจะมีรหัสผ่านที่แสดงบน Wireshark

การพิสูจน์ตัวตนพื้นฐานใช้การเข้ารหัสฐาน64เพื่อสร้างสตริงการเข้ารหัสซึ่งมีข้อมูลชื่อผู้ใช้และรหัสผ่าน

การตรวจสอบสิทธิ์การเข้าถึงแบบแยกย่อยใช้วิธีการแฮชเพื่อสร้างผลลัพธ์การเข้ารหัส