মোবাইল অ্যাপ্লিকেশনগুলিতে OAuth গোপনীয়তা


137

OAuth প্রোটোকলটি ব্যবহার করার সময়, আপনি যে পরিষেবাদিটি অর্পণ করতে চান সেখান থেকে আপনার একটি গোপন স্ট্রিং দরকার। আপনি যদি কোনও ওয়েব অ্যাপ্লিকেশনটিতে এটি করছেন, আপনি কেবল গোপনীয়তাটি আপনার ডেটা বেসে বা ফাইল সিস্টেমে সংরক্ষণ করতে পারেন, তবে এটি কোনও মোবাইল অ্যাপে (বা সেই বিষয়ে কোনও ডেস্কটপ অ্যাপ) হ্যান্ডেল করার সর্বোত্তম উপায় কী?

অ্যাপটিতে স্ট্রিং সংরক্ষণ করা স্পষ্টতই ভাল নয়, কারণ কেউ সহজেই এটি খুঁজে পেতে পারে এবং এটিকে অপব্যবহার করতে পারে।

আর একটি পদ্ধতি হ'ল এটি আপনার সার্ভারে সঞ্চয় করা এবং অ্যাপটি এটি প্রতিটি রানেই আনতে হবে, এটি কখনই ফোনে স্টোর করবেন না। এটি প্রায় হিসাবে খারাপ, কারণ আপনাকে অ্যাপ্লিকেশনটিতে ইউআরএল অন্তর্ভুক্ত করতে হবে।

একমাত্র কার্যক্ষম সমাধান যা আমি সামনে আসতে পারি তা হ'ল প্রথমে অ্যাক্সেস টোকনকে স্বাভাবিক হিসাবে গ্রহণ করা (পছন্দমতো অ্যাপের অভ্যন্তরে কোনও ওয়েব ভিউ ব্যবহার করে), এবং তারপরে আমাদের সার্ভারের মাধ্যমে আরও সমস্ত যোগাযোগের পথটি রেকর্ড করা যা অনুরোধের তথ্যের গোপনীয়তা যুক্ত করে এবং যোগাযোগ করবে সরবরাহকারীর সাথে তারপরে আবার, আমি একটি সুরক্ষার ব্যবস্থা, তাই আমি এই বিষয়ে কিছু জ্ঞানী লোকের মতামত শুনতে চাই। আমার কাছে দেখে মনে হয় না যে বেশিরভাগ অ্যাপ্লিকেশন সুরক্ষার গ্যারান্টি দিতে এই দৈর্ঘ্যে চলেছে (উদাহরণস্বরূপ, ফেসবুক কানেক্টটি মনে হয় যে আপনি গোপনীয়তাটি আপনার অ্যাপ্লিকেশনের ডানদিকে রেখেছেন)।

আরেকটি জিনিস: আমি বিশ্বাস করি না গোপনীয়তাটি প্রাথমিকভাবে অ্যাক্সেস টোকেনের অনুরোধের সাথে জড়িত ছিল, যাতে এটি আমাদের নিজস্ব সার্ভারকে জড়িত না করেই করা যায়। আমি কি সঠিক?


দুঃখিত যদি আমি সুস্পষ্ট না পাই তবে অ্যাপ্লিকেশনটির ডাটাবেসে কোডগুলি সংরক্ষণ করতে সমস্যা কি? কারণ এই টোকেনগুলি ব্যবহারকারী তার অ্যাকাউন্টটি প্রমাণীকরণের পরে উত্পন্ন এবং সঞ্চয় করা হয়, তাই এটি ধরে নেওয়া নিরাপদ হওয়া উচিত যে ব্যবহারকারী বলেছেন যে মোবাইল ডিভাইসটি অ্যাক্সেস রাখতে সঞ্চয় করতে চায়।
পোকে

এমনকি ব্যবহারকারী আপনাকে তাদের অ্যাকাউন্ট অ্যাক্সেস করার অনুমতি দেওয়ার পরেও (টুইটারে, বলুন) আপনি যে গোপনীয়তাটি ব্যবহার করতে চান সেবার থেকে আপনি যে গোপনীয়তাটি পেয়েছেন তা ব্যবহার করতে হবে। এই গোপনীয়তা প্রমাণীকরণ কী এবং কিছু অন্যান্য কীগুলির সাথে তাদের সার্ভারের সাথে সমস্ত যোগাযোগে ব্যবহৃত হয় । সুতরাং হ্যাঁ, আপনি অ্যাক্সেস কী সঞ্চয় করতে পারেন তবে গোপনীয়তাটি সংরক্ষণ করা উচিত নয়, কারণ পরিষেবাটি আপত্তিজনক কোনও প্রমাণীকরণ কী দিয়ে এটি ব্যবহার করা যেতে পারে । আবার, যারা এই সম্পর্কে আরও জানেন তাদের দ্বারা সংশোধন করে আমি খুশি হব।
ফেলিক্সিজ

1
OAuth একটি প্রমাণীকরণ পদ্ধতি সরবরাহ করে যা মূল ব্যবহারকারীর লগইন ডেটা সুরক্ষিত করে। এটি সম্ভব করার জন্য একটি নতুন অনন্য লগইন সংমিশ্রণ তৈরি করা হয়েছে যা কেবলমাত্র অনন্য অ্যাপ্লিকেশনের কী সংমিশ্রণের সাথে একসাথে কাজ করে । ব্যবহারকারীর লগইন ডেটা সংরক্ষণ করার বড় সুবিধা হ'ল এটি প্রথম অনুমোদনের পরে সম্পূর্ণ নিরাপদ এবং কোনও লঙ্ঘনের ক্ষেত্রে ব্যবহারকারী কেবল অনুমোদনের অ্যাক্সেস প্রত্যাহার করতে পারেন। এবং অবশ্যই গোপনীয় সংরক্ষণ না করা অর্থহীন হবে না কারণ ব্যবহারকারীর তখন পুনরায় প্রমাণ করা প্রয়োজন হবে (এবং অ্যাপ্লিকেশন অ্যাক্সেস দেওয়ার সময় ব্যবহারকারী এটি চায় না)।
অকর্মা

@ পোক যখন সরবরাহকারীর সাথে আপনার অ্যাপ্লিকেশন অনুমোদনের সময় প্রাপ্ত প্রমাণীকরণ কীটি সংরক্ষণ করা উচিত তবে অ্যাপটি প্রকাশের আগে আপনি সরবরাহকারীর কাছ থেকে প্রাপ্ত গোপন টোকেনটি (ডেস্কটপ বা মোবাইল অ্যাপ্লিকেশনটির ক্ষেত্রে তা করা উচিত নয়) যদি তা হয় একটি ওয়েব অ্যাপ্লিকেশন আপনি সার্ভারে স্পষ্টতই কীটি সঞ্চয় করতে পারবেন, যেমন প্রশ্নে বলা হয়েছে)।
ফেলিক্সিজ

4
ওআউথ সম্পর্কে আমার ধারণা অনুসারে - কোনও ডেস্কটপ অ্যাপ্লিকেশানের ক্ষেত্রে এইচআইটিপি / এইচটিটিপিএস ট্র্যাফিককে এই জাতীয় সরঞ্জামগুলির সাথে স্নিফ করা / পর্যবেক্ষণ করা খুব সহজ easy সুতরাং আপনার টোকেন এবং টোকেন গোপন উভয়ই খুব পাওয়া যায় can সহজে। সুতরাং একমাত্র সুরক্ষা হ'ল আপনার গ্রাহক-গোপন। এখন যদি আপনার স্টোরটি অ্যাপ্লিকেশনটির গোপনীয়তা এবং অন্য কেউ এটির সন্ধান করতে সক্ষম হয় তবে আপনার অ্যাপ্লিকেশন হিসাবে অন্য কোনও অ্যাপ্লিকেশনটি ছদ্মবেশ ধারণ করা বাচ্চার খেলা হয়ে যায়। আমি ভুল হলে আমাকে সংশোধন করুন।
বরুণ

উত্তর:


38

হ্যাঁ, এটি ওআউথ ডিজাইনের একটি সমস্যা যা আমরা নিজেরাই মুখোমুখি। আমরা আমাদের নিজস্ব সার্ভারের মাধ্যমে সমস্ত কলের প্রক্সি বেছে নিয়েছি। ডেস্কটপ অ্যাপ্লিকেশনগুলির ক্ষেত্রে ওআউথ পুরোপুরি শেষ হয়ে যায় নি। OAuth পরিবর্তন না করে আমি খুঁজে পেয়েছি এমন সমস্যার কোনও প্রিফেক্ট সমাধান নেই।

আপনি যদি এটি নিয়ে ভাবেন এবং আমাদের গোপনীয়তা কেন তা প্রশ্ন জিজ্ঞাসা করুন তবে বেশিরভাগই অ্যাপ্লিকেশন সরবরাহ ও অক্ষম করার জন্য। যদি আমাদের গোপনীয়তা আপস করা হয় তবে সরবরাহকারী কেবলমাত্র পুরো অ্যাপটি বাতিল করতে পারেন। যেহেতু আমাদের গোপনীয়তাটি আমাদের ডেস্কটপ অ্যাপ্লিকেশনটিতে এম্বেড করতে হয়, তাই আমরা বাঁচাচ্ছি।

সমাধানটি হ'ল প্রতিটি ডেস্কটপ অ্যাপ্লিকেশনটির জন্য আলাদা গোপন। OAuth এই ধারণাটি সহজ করে না। একটি উপায় হ'ল ব্যবহারকারী তার নিজের উপর একটি গোপন তৈরি করুন এবং নিজের ডেস্কটপ অ্যাপ্লিকেশনটিতে নিজের কীটি প্রবেশ করান (কিছু ফেসবুক অ্যাপ্লিকেশন দীর্ঘ সময় ধরে একই রকম কিছু করেছিল, ব্যবহারকারীকে যেতে এবং তাদের কাস্টম কোয়েস সেটআপ করার জন্য ফেসবুক তৈরি করতে এবং বিষ্ঠা)। এটি ব্যবহারকারীর পক্ষে দুর্দান্ত অভিজ্ঞতা নয়।

আমি OAuth এর জন্য একটি প্রতিনিধি সিস্টেমের প্রস্তাব নিয়ে কাজ করছি। ধারণাটি হ'ল যে আমাদের নিজস্ব গোপন কীটি আমরা আমাদের সরবরাহকারীর কাছ থেকে পাই, আমরা আমাদের নিজস্ব ডেস্কটপ ক্লায়েন্টগুলিকে (নিজস্বভাবে প্রতিটি ডেস্কটপ অ্যাপ্লিকেশনটির জন্য একটি) আমাদের নিজস্ব নির্ধারিত গোপনীয়তা জারি করতে পারি এবং তারপরে লেখার প্রক্রিয়া চলাকালীন আমরা সেই কীটি শীর্ষ স্তরে প্রেরণ করি সরবরাহকারী যা আমাদের কাছে ফিরে কল করে এবং আমাদের সাথে পুনরায় বৈধতা দেয়। এইভাবে আমরা প্রতিটি ডেস্কটপ ক্লায়েন্টকে ইস্যু করা নিজস্ব গোপনীয়তাগুলি প্রত্যাহার করতে পারি। (এসএসএল থেকে এটি কীভাবে কাজ করে তা অনেকটা ধার করা)। এই পুরো সিস্টেমটি ওয়েলড-অ্যাড ওয়েবসার্চেসের পাশাপাশি তৃতীয় পক্ষের ওয়েব সার্ভিসগুলিতে কল পাঠাতে পারে।

শীর্ষ স্তরের সরবরাহকারী নতুন ডেলিগ্রেটেড সিক্রেটগুলি উত্পন্ন এবং প্রত্যাহারের জন্য যদি কোনও এপিআই সরবরাহ করে তবে প্রক্রিয়াটি প্রতিনিধি যাচাইকরণ কলব্যাক ছাড়াইও করা যেতে পারে। ফেসবুক ব্যবহারকারীদের সাব-অ্যাপ্লিকেশন তৈরি করার অনুমতি দেওয়ার জন্য ফেসবুক অ্যাপ্লিকেশনগুলিকে মঞ্জুরি দিয়ে অনুরূপ কিছু করছে।

অনলাইনে বিষয়টি নিয়ে কিছু আলোচনা রয়েছে:

http://blog.atebit.com/2009/02/fixing-oauth/ http://groups.google.com/group/twitter-de વિકાસ ment- talk/ browse_thread/ thread/ 629b03475a3d78a1/ de1071bf4b820c14# de1071bf4b820c14

টুইটার এবং ইয়ামারের সমাধানটি একটি প্রমাণীকরণ পিন সমাধান: https://dev.twitter.com/oauth/pin- ভিত্তিক https://www.yammer.com/api_oauth_security_addendum.html


এটি অত্যন্ত আকর্ষণীয়, যদিও আমি যা ভয় পেয়েছিলাম তা এটি নিশ্চিত করে, ডেস্কটপ / মোবাইল অ্যাপ্লিকেশনগুলির জন্য ওআউথ এত দুর্দান্ত নয়। অবশ্যই, একজন আক্রমণকারীকে প্রথমে গোপনীয়তা পেতে হবে এবং তারপরে কারও শংসাপত্রগুলিও শুঁকতে হবে, সুতরাং এটি বেশ কিছুটা সংকল্প নিতে হবে take পিন সমাধান ডেস্কটপের জন্য ঠিক আছে তবে মোবাইল ইমোর জন্য ভারী হাতে।
ফেলিক্সিজ

আপনার প্রস্তাবিত স্কিমটি কীভাবে ওয়েব পরিষেবাগুলিকে মূল্য যুক্ত করতে সহায়তা করবে, যেহেতু এই সমস্যাটি তাদের জন্য প্রযোজ্য নয়? এছাড়াও, আমি দেখতে পাচ্ছি না যে এটি সরবরাহকারীর সাথে নতুন গোপনীয়তা তৈরি করার সাথে কীভাবে কাজ করবে, যেহেতু সেই নতুন গোপনগুলির জন্য অনুরোধ করার জন্য আপনার একটি "মাস্টার সিক্রেট" প্রয়োজন হবে, তাই আপনাকে কমপক্ষে নিজের সার্ভারে একটি কল প্রয়োজন হবে (যা এটি ধারণ করে প্রধান গোপন)। তবে এটি অবশ্যই আপনার নিজের সার্ভারের মাধ্যমে সমস্ত ট্র্যাফিকের রাউটিংয়ের চেয়ে ভাল । স্পষ্টকরণ সর্বাধিক স্বাগত! এবং আপনার প্রস্তাব অগ্রগতি হিসাবে দয়া করে এখানে আপডেট করুন!
ফেলিক্সিজ

5
কেবল কৌতূহলী: আপনি কীভাবে নির্ধারণ করবেন যে আপনার প্রক্সি সার্ভারে কল করা জিনিসটি বৈধ?
ডেভিডটবার্নাল

1
জিমের প্রতিক্রিয়ায়: আপনার গ্রাহক গোপনীয়তাটি বেরিয়ে আসার প্রাথমিক ঝুঁকিটি হ'ল দূষিত (বা বোকামি) অ্যাপ্লিকেশনগুলি এটি ব্যবহার করে তৈরি করা যেতে পারে, আপনার খ্যাতিকে কলঙ্কিত করে এবং আপনার এপিআই এর অপব্যবহার / অপব্যবহারের জন্য আপনার বৈধ অ্যাপ্লিকেশনটি বন্ধ করে দেওয়ার ঝুঁকি বাড়িয়ে তোলে। আপনার নিয়ন্ত্রণ করা কোনও ওয়েব অ্যাপ্লিকেশনের মাধ্যমে আপনার গোপনীয়তার জন্য প্রয়োজনীয় সমস্ত কল প্রক্সিং করে আপনি আবার এমন অবস্থানে ফিরে এসেছেন যেখানে আপনি যে এআইপি খাচ্ছেন তা বন্ধ করার সিদ্ধান্ত নেওয়ার আগে আপনি ব্যবহারকারীর অ্যাক্সেস প্রত্যাহার করতে পারেন বা টোকেন স্তরে অ্যাক্সেস প্রত্যাহার করতে পারেন you আপনার সম্পূর্ণ পরিষেবা নিচে।
Quasistoic

আমি এখানে কোয়াস্টিস্টিকের সাথে একমত, ওউথ কল মোকাবেলা করতে আপনাকে একটি এসএসএল সক্ষম ব্রাউজার ব্যবহার করতে হবে। ভবিষ্যতে সহজেই কোনও সুরক্ষা আপডেট পরিচালনা সহ কয়েকটি কারণে এটি একটি ভাল জিনিস এবং প্রকৃত প্রয়োগের কোনও কিছুই সময়ের সাথে সাথে আপডেট করার প্রয়োজন হবে না। জ্যাক টুইটারটিকে একটি পিন সমাধানের প্রস্তাব দিয়েছিল, যা আমি আসলেও ভেবেছিলাম, কারণ আপনি কোডটি সুরক্ষিতভাবে পাওয়ার জন্য অ্যাপ্লিকেশনটিতে বিশ্বাস করতে পারবেন না। আমি পিনের সাথে একটি আধুনিক এনক্রিপশন সহ একটি 'ননস' ব্যবহার করার পরামর্শ দিচ্ছি এবং ওয়েব সার্ভারের মাধ্যমে অনুরোধগুলির প্রক্সির গোপনীয়।
চিহ্নিত করুন

18

OAUth 2.0 দিয়ে, আপনি সার্ভারে গোপনীয়তা সঞ্চয় করতে পারেন। অ্যাক্সেস টোকেন অর্জন করতে সার্ভারটি ব্যবহার করুন যা আপনি তারপরে অ্যাপ্লিকেশনটিতে চলে যান এবং আপনি অ্যাপ্লিকেশন থেকে সরাসরি রিসোর্সে কল করতে পারেন।

OAuth 1.0 (টুইটার) এর সাথে, এপিআই কল করার জন্য গোপনীয়তার প্রয়োজন হয়। সার্ভারের মাধ্যমে কলগুলি প্রক্সিং করা গোপনীয়তার সাথে আপোস না হওয়ার বিষয়টি নিশ্চিত করার একমাত্র উপায়।

উভয়েরই এমন কিছু ব্যবস্থা দরকার যা আপনার সার্ভারের উপাদানটি জানেন যে এটি আপনার ক্লায়েন্টকে কল করছে। এটি আপনার সার্ভারে কল করার জন্য কোনও ধরণের অ্যাপ্লিকেশন আইডি পাওয়ার জন্য প্ল্যাটফর্ম নির্দিষ্ট মেকানিজমটি ইনস্টল করে এবং প্ল্যাটফর্মের সাহায্যে করা হয়ে থাকে on

(আমি OAuth 2.0 বৈশিষ্ট্যের সম্পাদক)


2
আপনি কি "কোনও ধরণের অ্যাপ আইডি পাওয়ার জন্য প্ল্যাটফর্ম নির্দিষ্ট পদ্ধতিতে" বিস্তারিত বর্ণনা করতে পারেন? ক্লায়েন্টের পরিচয় যাচাই করার জন্য সার্ভার উপাদানটি কীভাবে হয়? আমি মনে করি ক্লায়েন্টের বিধান দিয়ে এটি করা যেতে পারে। উদাহরণস্বরূপ, প্রতিটি ক্লায়েন্টের জন্য একটি নতুন এবং অনন্য এসএসএল শংসাপত্র স্থাপন করুন। তুমি কি এটাই বুজাতে চাও? যদি এটি এর চেয়ে জটিল হয় তবে আপনি আরও গভীরতর লেখার জন্য উল্লেখ করতে পারেন?
চিজো

2
আমি কিছু সুরক্ষিত লোককে স্মরণ করিয়ে দিচ্ছি যে এটি কীভাবে করা যায় about ওএস-এ একটি কল রয়েছে যা স্বাক্ষরিত টোকেনটি ফেরত দেয় যা আপনি আপনার সার্ভারে প্রেরণ এবং যাচাই করতে পারবেন। দুঃখিত আমি স্পেসিফিকেশন নেই। এটি এমন একটি ত্রুটি যা কিছু ভাল উদাহরণ ব্যবহার করতে পারে।
ডিক হার্ড্ট

2
@ ডিকহার্ড কিন্তু এই দৃশ্যে আপনি কীভাবে নিশ্চিত করতে পারেন যে মোবাইল অ্যাপ্লিকেশনটি সত্যই আপনার অ্যাপ্লিকেশন এবং কোনও প্রতারণামূলক নয়?
রাফেল মেমব্রিজ

11

একটি সমাধান হ'ল কোডটিতে OAuth গোপনীয়তার হার্ড কোড করা, তবে সাধারণ স্ট্রিং হিসাবে নয় । এটিকে কোনও উপায়ে অবলম্বন করুন - এটিকে বিভাগগুলিতে বিভক্ত করুন, একটি অফসেট দ্বারা অক্ষর স্থানান্তর করুন, এটিকে ঘোরান - এই যেকোন বা সমস্ত কিছু করুন। একটি ক্র্যাকার আপনার বাইট কোডটি বিশ্লেষণ করতে পারে এবং স্ট্রিংগুলি খুঁজে পেতে পারে তবে অবলম্বন কোডটি বের করা কঠিন be

এটি একটি বোকা সমাধান নয়, একটি সস্তা সমাধান।

শোষণের মানের উপর নির্ভর করে কিছু প্রতিভা ক্র্যাকার আপনার গোপন কোড খুঁজে পেতে আরও বেশি দৈর্ঘ্যে যেতে পারে। আপনার পূর্বে উল্লিখিত সার্ভারের পার্শ্ব সমাধানের ব্যয়, ক্র্যাকারদের আপনার গোপন কোডটি সন্ধানের জন্য আরও প্রচেষ্টা ব্যয় করার জন্য উত্সাহ এবং আপনার প্রয়োগ করতে পারে এমন জটিলতার জটিলতাগুলি আপনাকে বিবেচনা করতে হবে।


1
হ্যাঁ আমি এটি যুক্তিসঙ্গত মনে করি। কারও পক্ষে প্রথমে গ্রাহকের গোপনীয়তা বের করে নেওয়া এবং তারপরে কিছু অর্থ করার জন্য লোকদের শংসাপত্র ছিনিয়ে নেওয়া অনেক সংকল্প গ্রহণ করবে। হাই-প্রোফাইল অ্যাপ্লিকেশনগুলির জন্য, আমি নিশ্চিত নই যে এটি যথেষ্ট হবে তবে আমি মনে করি একটি গড় অ্যাপ্লিকেশনটির জন্য আপনি ঠিক বলেছেন যে আপনাকে বেশিরভাগ ছোটখাটো সুরক্ষা হুমকির বিরুদ্ধে বাস্তবায়নের সময় ভারসাম্য বজায় রাখতে হবে।
ফেলিক্সিজ

7
এক ব্যবহারকারীকে প্রচেষ্টা চালিয়ে যাওয়া এবং তারপরে আপনার গোপনীয়তা প্রকাশ করা বা ভাগ করে নেওয়া কেবল এটিই লাগে। আপনার গোপনীয়তাটি বের হয়ে যাওয়ার পরে, আপত্তিজনক স্ক্রোককেটের জন্য আপনার পরিষেবাটি পুরোপুরি বন্ধ হয়ে যাওয়ার ঝুঁকি এবং এটি পুরোপুরি আপনার নিয়ন্ত্রণের বাইরে চলে যায়।
quasistoic

8
উদ্বিগ্নতা মোটেই সুরক্ষা নয়। এটি মোটেও কোনও সুরক্ষার চেয়ে খারাপ, কারণ এটি বিকাশকারীকে নিরাপত্তার একটি মিথ্যা ধারণা দেয়। en.wikedia.org/wiki/Security_through_obscistance
পল লেগাতো

8
"অস্পষ্টতা মোটেই সুরক্ষা নয় This এটি কোনও সুরক্ষার চেয়েও খারাপ, কারণ এটি বিকাশকারীকে নিরাপত্তার একটি মিথ্যা ধারণা দেয়" " আজেবাজে কথা. কেউ বলছেন না যে অবক্ষয় ভাল সুরক্ষার জন্য করে for তবে আমি যদি আমার এপিপির সাথে একটি ওআউথ গোপনীয়তা বিতরণ করতে যাচ্ছি তবে অবশ্যই এটির চেয়ে অবলম্বন করা ভাল। অ্যাপ্লিকেশন কী / গোপনীয়তা সঞ্চয় করার সময় গুগলও সেই পরামর্শ দেয় Ob অন্য কিছু না হলে, এই ব্যবস্থাগুলি নৈমিত্তিক হ্যাকারগুলিকে উপসাগরীয় করে রাখে, যা কোনও কিছুর চেয়ে ভাল। আপনার মতো কম্বল স্টেটমেন্টগুলি কোনও সুরক্ষা না দিয়ে অসম্পূর্ণ সুরক্ষার সমান। এটি কেবল সত্য নয়। অপূর্ণতা কেবল অসম্পূর্ণ।
ক্ষুধার্তি

1
অবিবেচনা সাহায্য করে না, কারণ আপনি যতটা স্থানান্তরিত বা এনকোডিং করেন না কেন আপনি এখনও কীটি একসাথে তৈরি করেন এবং এটি আপনার API অনুরোধটি তৈরি করতে ব্যবহার করেন। আপনি এইচটিটিপিএস এনক্রিপশন করার আগে যে অনুরোধটি পাঠাচ্ছেন তা ডান করে দেওয়ার জন্য সঠিক জায়গায় API গুলিকে ডায়নামিকভাবে হুক করা সহজ। সুতরাং দয়া করে, যদি না সম্ভাব্য বিকল্প থাকে তবে আপনার অ্যাপে গোপন কীগুলি এম্বেড করবেন না।
C0deH4cker

6

অ্যাপ্লিকেশন ভিতরে গোপন সংরক্ষণ করবেন না।

আপনার https (স্পষ্টতই) এর মাধ্যমে অ্যাপ্লিকেশন দ্বারা অ্যাক্সেস করা যেতে পারে এমন একটি সার্ভার থাকা দরকার এবং আপনি এটিতে গোপনীয়তা সঞ্চয় করেন।

যখন কেউ আপনার মোবাইল / ডেস্কটপ অ্যাপ্লিকেশনটির মাধ্যমে লগইন করতে চান, আপনার অ্যাপ্লিকেশনটি কেবল সেই অনুরোধটি সার্ভারে প্রেরণ করবে যা গোপনীয়তাকে সংযুক্ত করে পরিষেবা সরবরাহকারীর কাছে প্রেরণ করবে। আপনার সার্ভারটি আপনার অ্যাপ্লিকেশনটি যদি সফল হয় বা না তা বলতে পারে।

তারপরে যদি আপনাকে পরিষেবা (ফেসবুক, গুগল, টুইটার, ইত্যাদি) থেকে কোনও সংবেদনশীল তথ্য পাওয়ার প্রয়োজন হয় তবে অ্যাপ্লিকেশনটি আপনার সার্ভারকে জিজ্ঞাসা করবে এবং আপনার সার্ভারটি সঠিকভাবে সংযুক্ত থাকলেই অ্যাপ্লিকেশনটিকে তা দেবে।

এটি কোনও সার্ভারে স্টোর করা ব্যতীত অন্য কোনও বিকল্প নেই। ক্লায়েন্ট পক্ষের কিছুই নিরাপদ নয়।

বিঃদ্রঃ

এটি বলেছে, এটি কেবল আপনাকে দূষিত ক্লায়েন্টের বিরুদ্ধে সুরক্ষা দেবে তবে ক্ষতিকারক বিরুদ্ধে ক্লায়েন্টকে নয় অন্য ক্ষতিকারক ক্লায়েন্টদের বিরুদ্ধে (ক্লায়েন্ট) নয় ...

ওআউথ হ'ল ডেস্কটপ / মোবাইলের চেয়ে ব্রাউজারে আরও ভাল প্রোটোকল।


1
এটি হ্যাকারের জীবনকে সহজ করে না ?! কারণ এখন, সার্ভারের সংস্থানগুলি অ্যাক্সেস করার জন্য আমাদের প্রযুক্তিগতভাবে ক্লায়েন্ট আইডি দরকার, যেহেতু সার্ভারটি যাইহোক অনুরোধটির গোপনীয়তা যুক্ত করবে। আমি কিছু অনুপস্থিত করছি?
হুদি ইলফিল্ড

@ হুডিআইফিল্ড হ্যাঁ আপনি কিছু মিস করছেন: ক্লায়েন্টটির সার্ভারে লগইন করা দরকার। যতক্ষণ না তিনি লগইন করছেন ততক্ষণ সার্ভার কোনও কিছুই ফিরিয়ে দেবে না। এটি পরিচালনা করার একটি উপায় হ'ল প্রথমবারের জন্য শংসাপত্র প্রেরণের পরে, সার্ভারটি ক্লায়েন্টকে একটি অ্যাক্সেস টোকেন ফিরিয়ে দেয় এবং তারপরে ক্লায়েন্ট ভবিষ্যতের প্রতিটি অনুরোধের সাথে এই অ্যাক্সেস টোকেনটি প্রেরণ করে। এখানে অনেকগুলি বিকল্প রয়েছে।
গুদ্রাদাইন

4

কোড এক্সচেঞ্জের জন্য প্রুফ কী নামে অনুমোদনের কোড গ্রান্ট প্রকারে একটি নতুন এক্সটেনশন রয়েছে (পিকেসিই) । এটির সাথে আপনার কোনও ক্লায়েন্ট সিক্রেটের দরকার নেই।

পিকেসিই (আরএফসি 7636) এমন একটি কৌশল যা সর্বজনীন ক্লায়েন্টকে সুরক্ষিত করার জন্য যা ক্লায়েন্টের গোপনীয়তা ব্যবহার করে না।

এটি প্রাথমিকভাবে দেশী এবং মোবাইল অ্যাপ্লিকেশন দ্বারা ব্যবহৃত হয়, তবে কৌশলটি যে কোনও পাবলিক ক্লায়েন্টের জন্যও প্রয়োগ করা যেতে পারে। অনুমোদনের সার্ভারের জন্য এটির অতিরিক্ত সমর্থন প্রয়োজন, সুতরাং এটি কেবলমাত্র নির্দিষ্ট সরবরাহকারীদের পক্ষে সমর্থিত।

https://oauth.net/2/pkce/ থেকে

আরও তথ্যের জন্য, আপনি সম্পূর্ণ আরএফসি 7636 বা এই সংক্ষিপ্ত ভূমিকাটি পড়তে পারেন ।


2

এখানে কিছু ভাবার কথা। গুগল ওয়েব অ্যাপ্লিকেশনগুলির জন্য ওআউথের দুটি পদ্ধতি সরবরাহ করে ... যেখানে আপনি ডোমেনটি নিবন্ধভুক্ত করেন এবং একটি অনন্য কী তৈরি করেন এবং ইনস্টলড অ্যাপ্লিকেশনগুলির জন্য যেখানে আপনি কী "বেনামে" কী ব্যবহার করেন।

সম্ভবত আমি পড়ার কিছু আবিষ্কার করেছি, তবে মনে হয় আপনার ওয়েব অ্যাপের অনন্য কীটি কোনও ইনস্টলড অ্যাপ্লিকেশনটির সাথে ভাগ করা সম্ভবত আনুষ্ঠানিকভাবে ইনস্টলড অ্যাপ্লিকেশন পদ্ধতিতে "বেনামে" ব্যবহার করা বেশি সুরক্ষিত।


2

OAuth 2.0 এর সাহায্যে আপনি অ্যাক্সেস টোকেন পেতে কেবল ক্লায়েন্টের সাইড প্রবাহটি ব্যবহার করতে পারেন এবং তারপরে আরও সমস্ত অনুরোধ প্রমাণ করতে এই অ্যাক্সেস টোকেনটি ব্যবহার করতে পারেন। তাহলে আপনার কোনও গোপনীয়তার দরকার নেই।

এটি কীভাবে বাস্তবায়ন করা যায় তার একটি সুন্দর বিবরণ এখানে পাওয়া যাবে: https://aaronparecki.com/articles/2012/07/29/1/oauth2-somplified#momot-apps


প্রদত্ত পরিষেবাটি "ক্লায়েন্টের পাশের প্রবাহ" সমর্থন করে। এই অ্যাক্সেস টোকেনটি পাওয়ার জন্য অনেকে ক্লায়েন্ট আইডি এবং ক্লায়েন্ট সিক্রেটের প্রয়োজন হয় না।
দামিয়ান ইয়ারিক

0

আমার কাছে ওআউথের সাথে এক টন অভিজ্ঞতা নেই - তবে প্রতিটি অনুরোধের জন্য কেবল ব্যবহারকারীর অ্যাক্সেস টোকেনই নয়, তবে একটি অ্যাপ্লিকেশন গ্রাহক কী এবং গোপনীয়তাও প্রয়োজন? সুতরাং, এমনকি যদি কেউ একটি মোবাইল ডিভাইস চুরি করে এবং এটি থেকে ডেটা টানতে চেষ্টা করে, আসলে কিছু করতে সক্ষম হওয়ার জন্য তাদের একটি অ্যাপ্লিকেশন কী এবং গোপনীয়তার প্রয়োজন হবে।

আমি সর্বদা ভেবেছিলাম ওআউথের পিছনে উদ্দেশ্যটি এমন ছিল যাতে প্রতিটি টম, ডিক এবং হ্যারি যে ম্যাসআপ করেছিল তাদের আপনার টুইটারের শংসাপত্রগুলি পরিষ্কার করে রাখতে হবে না। আমি মনে করি এটি সীমাবদ্ধতা থাকা সত্ত্বেও সমস্যাটি বেশ ভালভাবে সমাধান করে। এছাড়াও, এটি আইফোনের কথা মাথায় রেখে সত্যই ডিজাইন করা হয়নি।


আপনি ঠিক বলেছেন, ওআউথ বেশিরভাগ ক্ষেত্রে ওয়েব অ্যাপসটি মাথায় রেখে তৈরি করা হয়েছিল এবং আমি নিশ্চিত এটি এটির জন্য ভাল কাজ করে। হ্যাঁ প্রতিটি অনুরোধে স্বাক্ষর করার জন্য আপনার ভোক্তার টোকেন এবং গোপনীয়তা দরকার এবং গোপনটি কোথায় সংরক্ষণ করবেন তা সমস্যা। যদি কেউ অ্যাক্সেস কীটি চুরি করে তবে এটি কোনও বড় বিষয় নয় কারণ এটি প্রত্যাহারযোগ্য হতে পারে, তবে কেউ যদি গ্রাহক কী পান তবে আপনার অ্যাপ্লিকেশনটির প্রতিটি অনুলিপি আপস করা হয়েছে।
ফেলিক্সিজ

OAuth 1 প্রতিটি অনুরোধে স্বাক্ষর করা প্রয়োজন। OAuth 2 এর জন্য কেবল অ্যাক্সেস টোকেন প্রয়োজন। একটি টোকেন অর্জন করার সময় উভয়েরই কী এবং গোপনীয়তা প্রয়োজন।
ডিক হার্ড্ট 21

0

আমি ফেলিক্সিজের সাথে একমত OAuth বেসিক অথের চেয়ে ভাল, মোবাইল অ্যাপ্লিকেশনগুলির জন্য একটি ভাল সমাধান হতে এখনও অনেক দীর্ঘ পথ রয়েছে। আমি একটি গুগল অ্যাপ ইঞ্জিন অ্যাপ্লিকেশনটিতে মোবাইল ফোন অ্যাপ্লিকেশনটিকে প্রমাণীকরণ করতে OAuth ব্যবহার করে খেলছি। আপনি মোবাইল ডিভাইসে গ্রাহক গোপনীয়তার সাথে নির্ভরযোগ্যভাবে পরিচালনা করতে পারবেন না তার অর্থ ডিফল্ট হ'ল 'বেনামে' অ্যাক্সেস ব্যবহার করা।

গুগল অ্যাপ ইঞ্জিন ওআউথ প্রয়োগের ব্রাউজার অনুমোদনের পদক্ষেপ আপনাকে এমন একটি পৃষ্ঠায় নিয়ে যায় যেখানে এটিতে এমন পাঠ্য রয়েছে: "সাইট <some-Site> নীচে তালিকাভুক্ত পণ্যগুলির জন্য আপনার Google অ্যাকাউন্টে অ্যাক্সেসের জন্য অনুরোধ করছে"

আপনার অ্যাপ (yourapp.appspot.com) - গুগলের সাথে অনুমোদিত নয়

ইত্যাদি

কলব্যাক ইউআরএল ব্যবহার করা ডোমেন / হোস্ট নাম থেকে এটি <some-site> লাগে যা আপনি সরবরাহ করেন যা অ্যান্ড্রয়েডে যে কোনও কিছু হতে পারে যদি আপনি কলব্যাক বন্ধ করতে কোনও কাস্টম স্কিম ব্যবহার করেন। সুতরাং আপনি যদি 'বেনামি' অ্যাক্সেস ব্যবহার করেন বা আপনার গ্রাহক গোপনীয়তা আপস করা হয়, তবে যে কেউ এমন গ্রাহক লিখতে পারেন যা ব্যবহারকারীকে আপনার জিপি অ্যাপ্লিকেশনটিতে অ্যাক্সেস দেওয়ার ক্ষেত্রে বোকা বানাবে।

গুগল ওআউথ অনুমোদনের পৃষ্ঠায় প্রচুর সতর্কতা রয়েছে যা আপনি 'বেনামি', গ্রাহক গোপনীয়তা বা পাবলিক কী ব্যবহার করছেন কিনা তার উপর নির্ভর করে 3 স্তরের তীব্রতা রয়েছে।

প্রযুক্তিগতভাবে বুদ্ধিমান নয় এমন গড় ব্যবহারকারীর জন্য অত্যন্ত ভীতিজনক উপাদান। আমি সেই ধরণের স্টাফের সাথে সাইনআপ সমাপ্তির শতাংশের উচ্চমান আশা করি না।

এই ব্লগ পোস্টটি স্পষ্ট করে যে কীভাবে গ্রাহক গোপনীয়তা ইনস্টলড অ্যাপ্লিকেশনগুলির সাথে সত্যিই কাজ করে না। http://hueniverse.com/2009/02/should-twitter-discontinue-their-basic-auth-api/


0

আমি মোবাইল OAuth প্রমাণীকরণের জন্য একটি সমাধান এবং সাধারণভাবে অ্যাপ্লিকেশন বান্ডেলের মধ্যে গোপনীয়তাগুলি সংরক্ষণ করার চেষ্টা করছি।

এবং একটি পাগল ধারণাটি আমাকে কেবল আঘাত করেছে: সবচেয়ে সহজ ধারণাটি বাইনারিটির ভিতরে গোপনীয়তা সংরক্ষণ করা, তবে কোনওভাবে অবহেলা করা বা অন্য কথায়, আপনি একটি এনক্রিপ্ট করা গোপন সঞ্চয় করেন। সুতরাং, এর অর্থ হল আপনার গোপনটি ডিক্রিপ্ট করার জন্য আপনার কাছে একটি কী সঞ্চয় করতে হবে যা আমাদের পুরো বৃত্তটি নিয়েছে বলে মনে হচ্ছে। তবে, কেন কেবল একটি কী ব্যবহার করবেন না যা ইতিমধ্যে ওএস-এ রয়েছে, এটি আপনার অ্যাপ্লিকেশন দ্বারা নয় ওএস দ্বারা সংজ্ঞায়িত করা হয়েছে।

সুতরাং, আমার ধারণাটি স্পষ্ট করার জন্য আপনি ওএস দ্বারা সংজ্ঞায়িত একটি স্ট্রিং চয়ন করেন, এটি কোনটি বিবেচনা করে না। তারপরে এই স্ট্রিংটি কী হিসাবে ব্যবহার করে আপনার গোপনীয়তা এনক্রিপ্ট করুন এবং এটি আপনার অ্যাপ্লিকেশনটিতে সঞ্চয় করুন। তারপরে রানটাইমের সময়, কীটি ব্যবহার করে ভেরিয়েবলটি ডিক্রিপ্ট করুন যা কেবল একটি ওএস ধ্রুবক। আপনার বাইনারিতে উঁকি দেওয়ার কোনও হ্যাকার একটি এনক্রিপ্টড স্ট্রিং দেখতে পাবে, তবে কোনও কী নেই।

কাজ করবে?


3
ভাল চিন্তা, কিন্তু না। ক্র্যাকারটি কেবল বাইনারিটিকে ওএস ধ্রুবকের ঠিকানার দিকে নির্দেশ করবে।
গ্রেবি


0

ফেসবুক OAuth কঠোরভাবে বলতে (এখনও) প্রয়োগ করে না, তবে তারা আপনার আইফোনের অ্যাপে আপনার গোপনীয়তা এম্বেড না করার জন্য একটি উপায় কার্যকর করেছে: https://web.archive.org/web/20091223092924/http://wiki। developers.facebook.com/index.php/Session_Proxy

ওআউথের ক্ষেত্রে, হ্যাঁ, আমি এটি সম্পর্কে যত বেশি চিন্তা করি, আমরা কিছুটা স্টাফ। হয়তো এই এটা ঠিক করবে।


1
wiki.developers.facebook.com মারা গেছে।
হুগো

0

এই সমাধানগুলির কোনওটিই এইচটিপি শিরোলেখগুলিতে ক্লায়েন্টের গোপনীয়তা দেখতে তাদের মোবাইল ডিভাইস (বা এমুলেটর) থেকে প্রেরিত প্যাকেটগুলি স্নিফিং থেকে কোনও নির্ধারিত হ্যাকারকে আটকাতে পারে না।

একটি সমাধান হতে পারে একটি ডায়নামিক সিক্রেট যা একটি টাইমস্ট্যাম্পের সাথে প্রাইভেট 2-ওয়ে এনক্রিপশন কী এবং অ্যালগরিদম দিয়ে এনক্রিপ্ট করা থাকে। পরিষেবাটি তখন গোপনটি ডিক্রিপ্ট করে এবং সময় স্ট্যাম্পটি +/- 5 মিনিট কিনা তা নির্ধারণ করে।

এইভাবে, গোপনে আপস করা হলেও, হ্যাকার কেবলমাত্র সর্বোচ্চ 5 মিনিটের জন্য এটি ব্যবহার করতে সক্ষম হবে।


-2

অন্যরা যেমন উল্লেখ করেছে, ডিভাইসে স্থানীয়ভাবে গোপনীয়ত সংরক্ষণ করার কোনও সত্যিকারের সমস্যা হওয়া উচিত নয়।

সর্বোপরি, আপনি সর্বদা অ্যান্ড্রয়েডের ইউনিক্স-ভিত্তিক সুরক্ষা মডেলটির উপর নির্ভর করতে পারেন: আপনি কেবল ফাইল অ্যাপ্লিকেশনটিতে যা লিখবেন তা আপনার অ্যাপ্লিকেশনটি অ্যাক্সেস করতে পারে। আপনার অ্যাপের ডিফল্ট SharedPreferences অবজেক্টটিতে কেবল তথ্য লিখুন write

গোপনীয়তা পেতে, একজনকে অ্যান্ড্রয়েড ফোনে রুট অ্যাক্সেস নিতে হবে।


3
কে উল্লেখ করেছেন? যদি আপনি পোকের মন্তব্য বোঝাতে চান তবে আমার উত্তরটি সেই গোপনীয়তা! = প্রমাণীকরণ কীটি দেখুন। দ্বিতীয়টি নিরাপদে সংরক্ষণ করা যেতে পারে, আগেরটি পারে না। আমি অ্যান্ড্রয়েড সম্পর্কে জানি না, তবে আইফোনটিতে রুট অ্যাক্সেস পাওয়া মোটেই কঠিন নয়। নোট করুন যে অ্যাপ্লিকেশনটির সমস্ত ক্ষেত্রে গোপনীয়তা একই, সুতরাং আক্রমণকারীকে কেবলমাত্র একটি বাইনারি অ্যাক্সেস করতে হবে। এমনকি তারা ডিভাইসে রুট অ্যাক্সেস অর্জন করতে না পারলেও, তারা অন্য কোনও জায়গায় বাইনারিগুলিতে হাত পেতে এবং এটি থেকে গোপন টোকেনটি টেনে আনতে পারে।
ফেলিক্সিজ

1
কেবল যুক্ত করার জন্য এটি অ্যান্ড্রয়েড ফোনগুলিও রুট করা খুব সহজ
কেজিগ্রুটরিজ
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.