ความลับของ OAuth ในแอปมือถือ

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

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

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

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

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

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

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

วิธีแก้ปัญหาคือต้องมีความลับที่แตกต่างกันสำหรับแอปเดสก์ท็อปแต่ละตัว OAuth ไม่ได้ทำให้แนวคิดนี้ง่าย วิธีหนึ่งคือให้ผู้ใช้ไปสร้างความลับด้วยตัวเองและป้อนรหัสด้วยตัวเองลงในแอปเดสก์ท็อปของคุณ (แอพ facebook บางตัวทำคล้าย ๆ กันมานานแล้วโดยให้ผู้ใช้ไปและสร้าง facebook เพื่อตั้งค่า quizes ที่กำหนดเองและ อึ). ไม่ใช่ประสบการณ์ที่ดีสำหรับผู้ใช้

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

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

มีการพูดคุยเกี่ยวกับปัญหาออนไลน์:

http://blog.atebits.com/2009/02/fixing-oauth/ http://groups.google.com/group/twitter-development-talk/browse_thread/thread/629b03475a3d78a1/de1071bf4b820c14#de1071bf4b820c14

โซลูชันของ Twitter และ Yammer เป็นโซลูชันพินการตรวจสอบสิทธิ์: https://dev.twitter.com/oauth/pin-based https://www.yammer.com/api_oauth_security_addendum.html

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

ด้วย OAuth 1.0 (Twitter) จำเป็นต้องใช้ความลับในการเรียก API การเรียกพร็อกซีผ่านเซิร์ฟเวอร์เป็นวิธีเดียวที่จะทำให้ความลับไม่ถูกบุกรุก

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

(ฉันเป็นผู้แก้ไขข้อมูลจำเพาะ OAuth 2.0)

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

ไม่ใช่วิธีแก้ปัญหาที่เข้าใจผิด แต่เป็นวิธีที่ถูก

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

อย่าเก็บความลับไว้ในแอปพลิเคชัน

คุณต้องมีเซิร์ฟเวอร์ที่แอปพลิเคชันสามารถเข้าถึงได้ผ่านhttps (ชัดเจน) และคุณเก็บความลับไว้

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

จากนั้นหากคุณต้องการรับข้อมูลที่ละเอียดอ่อนใด ๆ จากบริการ (facebook, google, twitter ฯลฯ ) แอปพลิเคชันจะถามเซิร์ฟเวอร์ของคุณและเซิร์ฟเวอร์ของคุณจะให้ข้อมูลแก่แอปพลิเคชันต่อเมื่อมีการเชื่อมต่ออย่างถูกต้อง

ไม่มีตัวเลือกใด ๆ จริงๆยกเว้นการจัดเก็บไว้บนเซิร์ฟเวอร์ ไม่มีสิ่งใดในฝั่งไคลเอ็นต์ที่ปลอดภัย

บันทึก

ที่กล่าวว่านี่จะปกป้องคุณจากไคลเอนต์ที่เป็นอันตรายเท่านั้น แต่ไม่ใช่ไคลเอนต์จากการมุ่งร้ายคุณและไม่ใช่ไคลเอนต์จากไคลเอนต์ที่เป็นอันตรายอื่น ๆ (ฟิซิง) ...

OAuth เป็นโปรโตคอลที่ดีกว่าในเบราว์เซอร์มากกว่าบนเดสก์ท็อป / อุปกรณ์เคลื่อนที่

มีนามสกุลใหม่เพื่อการอนุญาตรหัสแกรนท์ประเภทเรียกว่าKey หลักฐานสำหรับรหัสตลาดหลักทรัพย์ (PKCE) ด้วยวิธีนี้คุณไม่จำเป็นต้องมีความลับของลูกค้า

PKCE (RFC 7636) เป็นเทคนิคในการรักษาความปลอดภัยไคลเอนต์สาธารณะที่ไม่ใช้ความลับไคลเอนต์

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

จากhttps://oauth.net/2/pkce/

สำหรับข้อมูลเพิ่มเติมคุณสามารถอ่านRFC 7636ฉบับเต็มหรือบทนำสั้น ๆนี้

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

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

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

สามารถดูคำอธิบายวิธีการใช้งานได้ที่นี่: https://aaronparecki.com/articles/2012/07/29/1/oauth2-simplified#mobile-apps

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

ฉันคิดเสมอว่าความตั้งใจที่อยู่เบื้องหลัง OAuth คือเพื่อให้ Tom, Dick และ Harry ทุกคนที่มี mashup ไม่จำเป็นต้องเก็บข้อมูลรับรอง Twitter ของคุณให้ชัดเจน ฉันคิดว่ามันช่วยแก้ปัญหานั้นได้ดีแม้ว่าจะมีข้อ จำกัด ก็ตาม นอกจากนี้ยังไม่ได้ออกแบบมาโดยคำนึงถึง iPhone จริงๆ

ฉันเห็นด้วยกับ Felixyz OAuth ในขณะที่ดีกว่า Basic Auth แต่ยังมีหนทางอีกยาวไกลที่จะเป็นทางออกที่ดีสำหรับแอปบนอุปกรณ์เคลื่อนที่ ฉันเล่นโดยใช้ OAuth เพื่อตรวจสอบสิทธิ์แอปโทรศัพท์มือถือกับแอป Google App Engine การที่คุณไม่สามารถจัดการความลับของผู้บริโภคบนอุปกรณ์เคลื่อนที่ได้อย่างน่าเชื่อถือหมายความว่าค่าเริ่มต้นคือการใช้การเข้าถึงแบบ "ไม่ระบุตัวตน"

ขั้นตอนการอนุญาตเบราว์เซอร์ของการติดตั้ง OAuth ของ Google App Engine จะนำคุณไปยังหน้าที่มีข้อความเช่น "ไซต์ <some-site> กำลังขอเข้าถึงบัญชี Google ของคุณสำหรับผลิตภัณฑ์ที่ระบุไว้ด้านล่าง"

YourApp (yourapp.appspot.com) - ไม่มีส่วนเกี่ยวข้องกับ Google

ฯลฯ

ใช้ <some-site> จากชื่อโดเมน / โฮสต์ที่ใช้ใน URL เรียกกลับที่คุณระบุซึ่งอาจเป็นอะไรก็ได้บน Android หากคุณใช้รูปแบบที่กำหนดเองเพื่อสกัดกั้นการโทรกลับ ดังนั้นหากคุณใช้การเข้าถึงแบบ "ไม่ระบุตัวตน" หรือความลับของผู้บริโภคของคุณถูกบุกรุกใคร ๆ ก็สามารถเขียนผู้บริโภคที่หลอกให้ผู้ใช้เข้าถึงแอป gae ของคุณได้

หน้าการให้สิทธิ์ Google OAuth ยังมีคำเตือนมากมายซึ่งมีความรุนแรง 3 ระดับขึ้นอยู่กับว่าคุณกำลังใช้ 'ไม่ระบุตัวตน' ความลับของผู้บริโภคหรือคีย์สาธารณะ

สิ่งที่น่ากลัวสำหรับผู้ใช้ทั่วไปที่ไม่เข้าใจในทางเทคนิค ฉันไม่คาดหวังว่าจะมีเปอร์เซ็นต์ความสำเร็จในการสมัครสูงกับสิ่งประเภทนั้นในทางนี้

บล็อกโพสต์นี้ชี้แจงว่าความลับของผู้บริโภคใช้ไม่ได้จริงกับแอปที่ติดตั้ง http://hueniverse.com/2009/02/should-twitter-discontinue-their-basic-auth-api/

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

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

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

จะได้ผลหรือไม่

ที่นี่ฉันมีคำตอบวิธีที่ปลอดภัยในการจัดเก็บข้อมูล oAuth ของคุณในแอปพลิเคชันมือถือ

https://stackoverflow.com/a/17359809/998483

https://sites.google.com/site/greateindiaclub/mobil-apps/ios/securelystoringoauthkeysiniosapplication

Facebook ไม่ได้ใช้ OAuth อย่างเคร่งครัด (ยัง) แต่พวกเขาได้ใช้วิธีที่ไม่ให้คุณฝังความลับของคุณในแอพ iPhone ของคุณ: https://web.archive.org/web/20091223092924/http://wiki Developers.facebook.com/index.php/Session_Proxy

สำหรับ OAuth ใช่ยิ่งฉันคิดเกี่ยวกับเรื่องนี้เราก็ยัดเยียด บางทีนี่อาจจะแก้ไขได้

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

วิธีแก้ปัญหาหนึ่งคือการมีความลับแบบไดนามิกซึ่งประกอบด้วยการประทับเวลาที่เข้ารหัสด้วยคีย์และอัลกอริทึมการเข้ารหัส 2 ทางส่วนตัว จากนั้นบริการจะถอดรหัสความลับและกำหนดว่าการประทับเวลาคือ +/- 5 นาทีหรือไม่

ด้วยวิธีนี้แม้ว่าความลับจะถูกบุกรุก แต่แฮ็กเกอร์จะสามารถใช้งานได้สูงสุด 5 นาทีเท่านั้น

ตามที่คนอื่น ๆ กล่าวไว้ไม่ควรมีปัญหาในการจัดเก็บความลับไว้ในเครื่อง

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

เพื่อให้ได้ความลับเราจะต้องได้รับการเข้าถึงรูทของโทรศัพท์ Android