การออกแบบการพิสูจน์ตัวตนสำหรับ REST API


11

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

ฉันกำลังทำสิ่งนี้ตามข้อเท็จจริงต่อไปนี้เกี่ยวกับสแต็กแอปพลิเคชัน:

  1. ไคลเอ็นต์ & เซิร์ฟเวอร์อยู่ใน. NET4 (ส่วนลูกค้าในโปรไฟล์ลูกค้า)
  2. เซิร์ฟเวอร์แสดงโดยใช้ WCF REST
  3. ฉันไม่ต้องการเก็บชื่อผู้ใช้และรหัสผ่านไว้ในหน่วยความจำในแอพ

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

  1. ก่อนที่ลูกค้าจะพยายามพิสูจน์ตัวตนมันจะสร้างคู่คีย์ Diffie-Hellman โดยใช้ECDiffieHellmanCngคลาส
  2. มันจะส่งส่วนสาธารณะของคู่กุญแจผ่านสายพร้อมกับชื่อผู้ใช้และรหัสผ่าน (ผ่าน HTTPS แน่นอน)
  3. เซิร์ฟเวอร์รับรองความถูกต้องของชื่อผู้ใช้ / รหัสผ่านหากทำสำเร็จจะทำสิ่งต่อไปนี้:
    1. สร้างโทเค็นเซสชันที่ไม่ซ้ำกัน
    2. สร้างคู่คีย์ DH ของตนเองและคำนวณความลับที่ใช้ร่วมกันจากพับลิกคีย์ที่ลูกค้าให้ไว้
    3. บันทึกโทเค็นเซสชันความลับที่ใช้ร่วมกันผู้ใช้และเวลา "การกระทำล่าสุด" (ใช้สำหรับหน้าต่างหมดอายุการหมุน) ในฐานข้อมูล
    4. ส่งคืนโทเค็นเซสชันคีย์สาธารณะ DH และข้อความยืนยันความสำเร็จในการตรวจสอบความถูกต้อง
  4. ไคลเอ็นต์ใช้คีย์ DH จากการตอบสนองคำนวณความลับที่ใช้ร่วมกันและเก็บทั้งโทเค็นและความลับในหน่วยความจำ

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

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

มีหลุมใดที่ใครสามารถกระตุ้นได้


ฉันไม่เห็นว่าการสร้างคีย์ DH นั้นเพิ่มความปลอดภัยใด ๆ เมื่อเทียบกับการใช้ HTTPS ทุกที่และการใช้คุกกี้เซสชันเก่าแบบธรรมดา เมื่อใช้อย่างถูกต้อง HTTPS จะป้องกันการโจมตีจากคนกลางและเล่นซ้ำแล้ว
Lie Ryan

คำตอบ:


5

แทนที่จะคิดค้นของคุณเองคุณควรพิจารณาที่จะอ่าน OpenAM API และยืมมัน

http://forgerock.com/openam.html

OpenAM Wiki มีประโยชน์อย่างยิ่ง

https://wikis.forgerock.org/confluence/display/openam/Home

คุณไม่จำเป็นต้องใช้องค์ประกอบของพวกเขา แต่ถ้าคุณใช้ API คุณจะพบว่าชีวิตของคุณจะง่ายขึ้นในระยะยาว


อืมมันไม่ได้ดูไม่ดีสิ่งหนึ่งที่ทำให้ฉันไม่สามารถใช้มันในกรณีนี้: เราเป็นร้านค้า. Net นอกจากนี้ยังมีไม่มากเกี่ยวกับการใช้งานกับด้านเซิร์ฟเวอร์ WCF ของสิ่งต่าง ๆ ลิงก์ที่ไม่ใช่สแปมลิงค์เดียวที่ฉันสามารถหาบน google เกี่ยวกับมันชี้ไปที่การใช้ WIF และ WS-Federation
Matt Sieker

1
@Matt Sieker: "คุณไม่จำเป็นต้องใช้ส่วนประกอบ" โปรดอ่านเกี่ยวกับ API ของพวกเขาแทนการประดิษฐ์ของคุณเอง
S.Lott

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

เราเริ่มต้นของเราเอง แต่แล้วก็ย้ายไป OpenAM เมื่อหลายปีก่อนที่กลุ่ม IG มีความสุขมากกับผลิตภัณฑ์โอเพ่นซอร์ส
Robert Morschel

2

ฉันเห็นด้วย 100% กับ @ S.Lott ว่าคุณไม่ต้องการหมุนตัวเอง ฉันขอแนะนำให้ดูทางเลือกอื่น: บริการควบคุมการเข้าถึง Windows Azure (ACS) ACS เป็นต้นทุนเงิน แต่มันถูกมาก (10,000 ธุรกรรมสำหรับ $ 0.01) และมีการจัดการโครงสร้างพื้นฐานที่ดี WIF ถูกใช้ประโยชน์จากลูกค้า

นี้ยังเป็นวิธีการแก้ปัญหาตามมาตรฐาน / เรียกร้องตาม - ซึ่งเป็นความโกรธทั้งหมด ตรวจสอบนี้บทความเกี่ยวกับการใช้ WCF และส่วนที่เหลือและเอซีเอสด้วยกัน

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

โชคดี! -บิล

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.