วิธีการพิสูจน์ตัวตนผู้ใช้จากแอปพลิเคชันไคลเอนต์

ฉันพัฒนาแอพพลิเคชั่นซึ่งจะรองรับผู้ใช้หลายคน สิ่งที่ฉันไม่สามารถคิดออกวิธีการตรวจสอบลูกค้า / ผู้ใช้

ฉันกำลังสร้างแอพอย่างhttp://quickblox.com/ที่ฉันจะให้ข้อมูลประจำตัวแก่ผู้ใช้ของฉันและพวกเขาจะใช้แอปเหล่านี้เพื่อสร้างแอปพลิเคชั่นNที่พวกเขาไม่สามารถใส่ชื่อผู้ใช้และรหัสผ่านเพื่อรับรองความถูกต้อง

สมมติว่ามันเป็นไปตาม(เหมือน QuickBlox)

1. ผู้ใช้สร้างบัญชีในเว็บไซต์ของฉัน
2. ผู้ใช้สามารถสร้างคีย์ N API และข้อมูลรับรองความลับ (สำหรับหลายแอพ)
3. ผู้ใช้จะใช้ข้อมูลรับรองเหล่านี้ในแอปพลิเคชัน (Android, iOS, Javascript ฯลฯ ... ) เพื่อพูดคุยกับ REST API ของฉัน
(REST API มีการเข้าถึงแบบอ่านและเขียน)

ความกังวลของฉัน?

ผู้ใช้จะใส่ข้อมูลประจำตัว (คีย์ API และคีย์หลั่ง) ในแอปพลิเคชันที่พวกเขาสร้างจะเกิดอะไรขึ้นถ้ามีคนรับคีย์เหล่านี้และพยายามเลียนแบบผู้ใช้ (โดยการแยกข้อมูล APK หรือดูโค้ด JavaScript โดยตรง

ฉันผิดตรงไหนเหรอ?
ฉันสับสนในการออกแบบกลไกผู้ใช้สามระดับนี้

ฉันได้รับการออกแบบ REST APIs ในช่วงไม่กี่ปีที่ผ่านมา คุณกังวลมากเกินไป เมื่อเร็ว ๆ นี้ผู้ใช้รายอื่นในบอร์ดนี้ได้ถามคำถามซึ่งเขากังวลเกี่ยวกับการจัดเก็บจุดสิ้นสุด URI ในรหัสฝั่งไคลเอ็นต์ JavaScript ของเขารหัสลูกค้าด้านข้างของเขา

ใช้กฎเดียวกันกับคุณเช่นเดียวกับผู้พัฒนา JavaScript หากคุณอนุญาตให้ผู้คนจากภายนอกรวม API ของคุณ API ของคุณจะมีการเปิดเผยเช่นเดียวกับเว็บไซต์ทั่วไปและคุณควรปฏิบัติเช่นเดียวกัน

อ้างอิงจากคำตอบเดิม:

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

REST API ของคุณควรแข็งแกร่งพอที่จะไม่อนุญาตการดำเนินการที่ไม่ถูกต้องเช่นการเข้าถึงข้อมูลจากผู้ใช้รายอื่น

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

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

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

หากคุณไม่ได้จัดการการพัฒนาแอพพลิเคชั่นที่ใช้ API ของคุณโดยตรงไม่มีสิ่งใดที่ห้ามไม่ให้ผู้คนใช้ API ของคุณในทางที่ผิดเช่นเดียวกับแอพโดยตรง

ปัญหาของคุณไม่ใช่ปัญหาด้านเทคนิคมากเท่ากับธุรกิจ

สมมติว่าคุณมี API ซึ่งคุณขายให้กับลูกค้าของคุณ (นักพัฒนาแอป) ในราคาเพียง 100 ปอนด์ต่อปีไม่ จำกัด การเข้าถึง

เห็นได้ชัดว่าฉันสามารถซื้อบริการของคุณได้ที่£ 100 และขายให้กับคน 10 คนในราคา $ 50 ต่อคน คุณไม่ต้องการที่! ดังนั้นคุณลองนึกถึงข้อ จำกัด ที่จะให้คุณขาย API โดยไม่ต้องเปิดให้มีการเก็งกำไร

• หากคุณเพียง จำกัด จำนวนแอพลูกค้าสามารถสร้างแอพเดียวที่ยอมรับการเชื่อมต่อจากแอพอื่นและส่งต่อได้

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

สิ่งที่คุณต้องทำคือส่งค่าใช้จ่ายของการเรียก API แต่ละครั้งไปยังลูกค้าของคุณ เช่นคิดค่าบริการต่อการโทร API หรือกำหนดโควต้าการโทรต่อปี

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

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

แน่นอนค่ะ

หลักการสองข้อ (รายละเอียดการนำไปปฏิบัติจะปฏิบัติตาม):

1. จุดสิ้นสุดการรับรองความถูกต้องจริงต้องเปิดโดยไม่ระบุตัวตนต่อสาธารณะ
2. เซิร์ฟเวอร์ต้องมีส่วนร่วมในการตรวจสอบสิทธิ์ไคลเอ็นต์และระบุคีย์ API

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

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

หากคุณพยายามหลีกเลี่ยงผู้ใช้ที่ตรวจสอบสิทธิ์ตัวเองอีกครั้งการตรวจสอบความถูกต้องนี้อาจเป็นการตั้งค่าเริ่มต้นครั้งเดียวในแอพเมื่อได้รับการติดตั้ง

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

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

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

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

เมื่อใดก็ตามที่การแลกเปลี่ยนกับไคลเอนต์ได้รับการซิงค์ (ข้อผิดพลาดของโปรโตคอลบางประเภท) เซิร์ฟเวอร์ของคุณจะขอการรับรองความถูกต้องอีกครั้ง (ผ่านการตอบกลับข้อผิดพลาดไปยังการร้องขอของลูกค้าต่อไปหรือ piggy-Backed ตัวอย่าง).

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

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

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

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

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

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

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

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

สิ่งนี้อาจหลงทางเล็กน้อยจากขอบเขตคำถามของคุณ แต่เกี่ยวข้องกับความปลอดภัยของโทเค็นของคุณดังนั้นฉันจะพูดถึงมัน เพื่อป้องกันการขโมยโทเค็นเล็กน้อยโดยใช้ลวดคุณอาจไม่ต้องการส่งโทเค็นโดยตรง แต่คุณสามารถลงชื่อเข้าใช้ทราฟฟิกโดยใช้ฟังก์ชัน HMAC คุณสามารถตรวจสอบความถูกต้องของข้อความโดยการคำนวณ HMAC ของข้อความบนเซิร์ฟเวอร์และเปรียบเทียบกับ HMAC ที่ส่งจากลูกค้า คุณจะใช้โทเค็นเป็นกุญแจสำคัญในฟังก์ชั่น HMAC ดังนั้นมีเพียงคนที่รู้โทเค็นเท่านั้นที่สามารถลงชื่อรับส่งข้อมูลได้ สิ่งนี้จะดีกว่าสำหรับความปลอดภัยของโทเค็นของคุณเพราะคุณไม่เคยส่งไปยังเซิร์ฟเวอร์โดยตรงดังนั้นจึงไม่สามารถดักจับและขโมยได้โดยตรง สำหรับข้อมูลเพิ่มเติมเกี่ยวกับ HMACS ดูคำถามนี้: /security/20129/how-and-when-do-i-use-hmac/20301

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

อ้างตัวเอง:

ฉันไม่สามารถทราบวิธีการตรวจสอบลูกค้า / ผู้ใช้ ... ซึ่งพวกเขาไม่สามารถใส่ชื่อผู้ใช้และรหัสผ่านเพื่อรับการตรวจสอบสิทธิ์

ทีนี้มันก็ขัดแย้งกันใช่มั้ย ;)

อย่างที่คนอื่นพูดคุณทำไม่ได้ หากแอพใช้รหัส API หนึ่งสามารถถอดรหัสได้ตามที่คุณพูดเพื่อรับรหัสและใช้งานเช่นกัน

นอกเหนือจากต้องการการรับรองความถูกต้องของผู้ใช้เพิ่มเติมคุณสามารถจำกัดความเสียหายได้เท่านั้น:

• IP ที่อนุญาต / ขึ้นบัญชีดำ
• การอุด
• การตรวจจับ "กิจกรรมที่ผิดปกติ" และแหล่งที่มา
• การต่ออายุคีย์ง่าย