แนวทางปฏิบัติที่ดีที่สุดเกี่ยวกับการสร้างโทเค็น OAuth?


101

ฉันตระหนักดีว่าข้อมูลจำเพาะ OAuthไม่ได้ระบุอะไรเกี่ยวกับที่มาของ ConsumerKey, ConsumerSecret, AccessToken, RequestToken, TokenSecret หรือรหัสผู้ตรวจสอบ แต่ฉันสงสัยว่ามีแนวทางปฏิบัติที่ดีที่สุดในการสร้างโทเค็นที่ปลอดภัยอย่างมีนัยสำคัญหรือไม่ (โดยเฉพาะโทเค็น / การรวมความลับ)

อย่างที่ฉันเห็นมีหลายวิธีในการสร้างโทเค็น:

  1. เพียงใช้ไบต์สุ่มเก็บในฐานข้อมูลที่เกี่ยวข้องกับผู้บริโภค / ผู้ใช้
  2. แฮชข้อมูลเฉพาะของผู้ใช้ / ผู้บริโภคจัดเก็บในฐานข้อมูลที่เกี่ยวข้องกับผู้บริโภค / ผู้ใช้
  3. เข้ารหัสข้อมูลเฉพาะผู้ใช้ / ผู้บริโภค

ข้อดีของ (1) คือฐานข้อมูลเป็นแหล่งข้อมูลเดียวที่ดูเหมือนปลอดภัยที่สุด มันจะยากกว่าที่จะโจมตีมากกว่า (2) หรือ (3)

การแฮ็กข้อมูลจริง (2) จะช่วยให้สามารถสร้างโทเค็นขึ้นมาใหม่จากข้อมูลที่น่าจะเป็นที่รู้จักอยู่แล้ว อาจไม่ได้ให้ประโยชน์ใด ๆ กับ (1) เนื่องจากจะต้องจัดเก็บ / ค้นหาอยู่ดี CPU เข้มข้นมากกว่า (1)

การเข้ารหัสข้อมูลจริง (3) จะช่วยให้การถอดรหัสทราบข้อมูล สิ่งนี้จะต้องใช้พื้นที่จัดเก็บน้อยกว่าและอาจมีการค้นหาน้อยกว่า (1) & (2) แต่ก็มีความปลอดภัยน้อยเช่นกัน

มีแนวทาง / ข้อดี / ข้อเสียอื่นใดที่ควรพิจารณา?

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

ติดตามคำถาม :

มีความยาวโทเค็นขั้นต่ำเพื่อให้มีความปลอดภัยในการเข้ารหัสอย่างมีนัยสำคัญหรือไม่? ตามที่ฉันเข้าใจแล้ว Token Secrets ที่ยาวขึ้นจะสร้างลายเซ็นที่ปลอดภัยมากขึ้น ความเข้าใจนี้ถูกต้องหรือไม่?

มีข้อดีในการใช้การเข้ารหัสที่เฉพาะเจาะจงจากมุมมองของการแฮชหรือไม่? ตัวอย่างเช่นฉันเห็น API จำนวนมากที่ใช้การเข้ารหัสฐานสิบหก (เช่นสตริง GUID) ในอัลกอริทึมการลงนาม OAuth โทเค็นจะใช้เป็นสตริง ด้วยสตริงฐานสิบหกชุดอักขระที่มีอยู่จะมีขนาดเล็กกว่ามาก (คาดเดาได้ง่ายกว่า) มากกว่าการเข้ารหัส Base64 สำหรับฉันแล้วดูเหมือนว่าสำหรับสองสตริงที่มีความยาวเท่ากันสตริงที่มีชุดอักขระที่ใหญ่กว่าจะมีการกระจายแฮชที่ดีกว่า / กว้างกว่า สำหรับฉันแล้วดูเหมือนว่ามันจะช่วยเพิ่มความปลอดภัย สมมติฐานนี้ถูกต้องหรือไม่?

ข้อมูลจำเพาะของ OAuth ยกปัญหานี้มากใน11.10 เอนโทรปีแห่งความลับ


ทำไมต้องเข้ารหัส? แฮชยังไม่ดีพอหรือ? หากการแฮชดีพอสำหรับรหัสผ่านมันควรจะดีกว่าสำหรับโทเค็นการเข้าถึงอีกต่อไปหรือ
AlikElzin-kilaka

เป็นเวลา 7.5 ปีแล้วที่ฉันถามคำถาม บอกตรงๆจำไม่ได้
mckamey

1
การอ่านอีกครั้งการแฮชและการเข้ารหัสเป็นแนวทางที่แตกต่างกันสองวิธีที่แนะนำ การเข้ารหัสจะช่วยให้เซิร์ฟเวอร์ได้รับข้อมูลบางอย่างโดยไม่ต้องค้นหาฐานข้อมูล มันเป็นการแลกเปลี่ยนหนึ่งในหลาย ๆ
mckamey

คำตอบ:


93

OAuth ไม่ได้พูดอะไรเกี่ยวกับโทเค็นยกเว้นว่ามีความลับเกี่ยวข้อง ดังนั้นแผนการทั้งหมดที่คุณกล่าวถึงจะใช้งานได้ โทเค็นของเราพัฒนาขึ้นเมื่อไซต์มีขนาดใหญ่ขึ้น นี่คือเวอร์ชันที่เราเคยใช้มาก่อน

  1. โทเค็นแรกของเราคือ BLOB ที่เข้ารหัสด้วยชื่อผู้ใช้ความลับโทเค็นและการหมดอายุเป็นต้นปัญหาคือเราไม่สามารถเพิกถอนโทเค็นโดยไม่มีการบันทึกใด ๆ บนโฮสต์

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

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

รายละเอียดการใช้งานบางอย่างที่อาจช่วยคุณได้

  1. เพิ่มเวอร์ชันในโทเค็นเพื่อให้คุณสามารถเปลี่ยนรูปแบบโทเค็นได้โดยไม่ทำลายสิ่งที่มีอยู่ โทเค็นทั้งหมดของเรามีไบต์แรกเป็นเวอร์ชัน
  2. ใช้ Base64 รุ่นที่ปลอดภัยสำหรับ URL ในการเข้ารหัส BLOB ดังนั้นคุณจึงไม่ต้องจัดการกับปัญหาการเข้ารหัส URL ซึ่งทำให้การดีบักด้วยลายเซ็น OAuth ทำได้ยากขึ้นเนื่องจากคุณอาจเห็นการเข้ารหัสพื้นฐานที่เข้ารหัสสามครั้ง

2
ยอดเยี่ยมขอบคุณ ความคิดรุ่นเป็นสิ่งที่ดี ฉันมี Base64 ที่เป็นมิตรกับ URL แต่ฉันต้องการให้มีการเข้ารหัสตัวอักษรและตัวเลขอย่างเคร่งครัดเพื่อการอ่านที่ง่ายยิ่งขึ้น
mckamey

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