การรักษาความปลอดภัย REST API: HMAC / การแฮ็กคีย์กับ JWT


16

ฉันเพิ่งอ่านบทความนี้ที่มีอายุไม่กี่ปี แต่อธิบายวิธีที่ชาญฉลาดในการรักษา REST API ของคุณ เป็นหลัก:

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

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


1
ฮ่า ๆ ๆ ... ฉันแค่อยากถามคำถามที่เหมือนกันและเจอคุณ หนึ่งในสิ่งแรกที่ฉันพบเกี่ยวกับการรับรองความถูกต้องแบบไร้รัฐนั้นมาจาก AWS: docs.aws.amazon.com/AmazonSimpleDB/latest/DeveloperGuide/และดำเนินการบางอย่างเช่นmassimilianosciacco.com/นี้ จากนั้นฉันก็พบ JWS / JWT และมันก็คล้ายกัน แต่เท่าที่ฉันเข้าใจ JWT เป็นมาตรฐานและวิธีแก้ปัญหาอื่น ๆ ที่อธิบายข้างต้นเป็นการใช้งานแบบกำหนดเองบางอย่าง (ไม่ใช่แบบมาตรฐาน) มีคนแก้ไขฉันถ้าฉันผิด
nyxz

2
เป็นการดีที่จะรู้ฉันไม่ใช่คนเดียวที่กังวลเกี่ยวกับรายละเอียดเหล่านี้! JWT รู้สึกเหมือนกันอย่างแน่นอนและโบนัสคือมันเป็นมาตรฐาน ฉันแค่สงสัยว่ามันยุติธรรม (ความปลอดภัย) กับโซลูชั่น HMAC ที่กำหนดเองนี้
smeeb

คำตอบ:


7

มาเริ่มกันด้วยคำตอบพื้นฐานกันดีกว่า

JWT (ตามที่ใช้ในบริบทของ OAuth และ OpenID) ไม่จำเป็นต้องใช้ความลับร่วมกันระหว่างไคลเอ็นต์และ API มี 3 องค์ประกอบและคู่ที่ 2 แบ่งปันความลับแต่ละ: ไคลเอนต์เซิร์ฟเวอร์การระบุ <->, เซิร์ฟเวอร์การระบุ <-> API

สิ่งนี้ย้ายความซับซ้อนส่วนใหญ่จาก API ไปยังเซิร์ฟเวอร์การระบุ API เพียงเพื่อตรวจสอบว่าโทเค็นออกโดยเซิร์ฟเวอร์การระบุและไม่ได้รับอารมณ์ ในการตรวจสอบว่า API ตรวจสอบว่า JWT-signature นั้นถูกต้องกับความลับร่วมกันที่รู้จักเดียวระหว่างเซิร์ฟเวอร์การระบุและ API แค่นั้นแหละ!

วิธีที่เซิร์ฟเวอร์การระบุตัวตนตรวจสอบข้อมูลประจำตัวของผู้ใช้อาจแตกต่างกันอย่างมาก (ในหลายกรณีมันเป็นชื่อผู้ใช้ + รหัสผ่านคู่เก่าผ่านการเชื่อมต่อ TLS) แต่ไม่มีผลกับ API ของคุณ

ความเป็นส่วนตัวและความปลอดภัยของข้อความและโทเค็นเองเมื่อใช้ JWT ได้รับการจัดการโดย TLS JWT ไม่ทราบถึงปัญหาดังกล่าว

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