ক্লায়েন্ট অ্যাপ্লিকেশনগুলি থেকে স্থপতি ব্যবহারকারী প্রমাণীকরণ কীভাবে?


14

আমি একটি অ্যাপ্লিকেশন বিকাশ করেছি যা অনেক ব্যবহারকারীকে সমর্থন করবে। জিনিসটি আমি কীভাবে ক্লায়েন্ট / ব্যবহারকারীকে প্রমাণীকরণ করব তা নির্ধারণ করতে অক্ষম।

আমি http://quickblox.com/ এর মতো একটি অ্যাপ তৈরি করছি যেখানে আমি আমার ব্যবহারকারীদের শংসাপত্র দেব এবং তারা এন অ্যাপ্লিকেশন তৈরি করতে ব্যবহার করবে যাতে তারা প্রমাণীকরণের জন্য তাদের ব্যবহারকারীর নাম এবং পাসওয়ার্ড রাখতে পারবেন না।

আসুন ধরে নেওয়া যাক এটি অনুসরণ হিসাবে যায়। (কুইকব্লক্সের মতো)

১. ব্যবহারকারী আমার ওয়েবসাইটে অ্যাকাউন্ট তৈরি করে।
২. ব্যবহারকারী এনপিআই কী এবং শংসাপত্রগুলি সেক্রেট করতে পারে। (একাধিক অ্যাপ্লিকেশানের জন্য)
৩. ব্যবহারকারীরা আমার অ্যাপ্লিকেশনগুলিতে (অ্যান্ড্রয়েড, আইওএস, জাভাস্ক্রিপ্ট ইত্যাদি ...) এই শংসাপত্রগুলি আমার REST এপিআইয়ের সাথে কথা বলার জন্য ব্যবহার করবে।
(REST এপিআইগুলি অ্যাক্সেস পড়তে এবং পড়তে পারে))

আমার উদ্বেগ?

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

আমি কোথাও ভুল করছি?
আমি এই তিন স্তরের ব্যবহারকারী প্রক্রিয়াটি স্থপতি করতে বিভ্রান্ত।


আপনি যে জিনিসটি করার চেষ্টা করছেন বলে মনে হচ্ছে তা সম্ভব নয়।
ব্যবহারকারী 253751

সেখানে অনেকগুলি অ্যাপ্লিকেশন রয়েছে যা একই জিনিসটি করে। আমি নিশ্চিত না যে তারা কীভাবে ব্যবহারকারীদের প্রমাণীকরণ করবে।
অলোক প্যাটেল

আপনি কি ক্লায়েন্ট অ্যাপ্লিকেশন , বা ব্যবহারকারীকে প্রমাণীকরণের চেষ্টা করছেন ? প্রচুর অ্যাপ ব্যবহারকারীদের প্রমাণীকরণ করে। এগুলির কোনওটিই অবিচ্ছিন্ন উপায়ে ক্লায়েন্ট অ্যাপ্লিকেশনগুলি প্রমাণীকরণ করে।
ব্যবহারকারী 253751

হ্যাঁ ক্লায়েন্টের অর্থ হ'ল আমি কেবলমাত্র ব্যবহারকারীকে প্রমাণীকরণ করতে চাই।
অলোক প্যাটেল

4
ওহ, তবে বেশিরভাগ সাধারণ প্রমাণীকরণ সিস্টেমে আপনি কেবলমাত্র ব্যবহারকারীকে তাদের ব্যবহারকারীর নাম এবং পাসওয়ার্ড প্রবেশ করিয়ে আনবেন এবং সেগুলিতে নিরাপদে প্রেরণ করুন যা তাদের পরীক্ষা করে এবং (নিরাপদে) একটি সেশন টোকেন ফিরিয়ে দেয় এবং তারপরে আপনি সেশন টোকেনটি প্রেরণ করেন প্রতিটি ভবিষ্যতের অনুরোধ।
ব্যবহারকারী 253751

উত্তর:


7

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

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

মূল উত্তর থেকে উদ্ধৃতি:

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

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

আপনার অ্যাপ্লিকেশন অ্যাক্সেস টোকেনগুলি কেবলমাত্র সেই ক্রিয়াকলাপের জন্য অনুমতি দেওয়া উচিত যা আপনি মঞ্জুর করতে চান be আপনার কাছে দুটি ধরণের অ্যাক্সেস টোকেন থাকতে পারে:

  • মাস্টার টোকেন : অ্যাপ্লিকেশন স্রষ্টার দ্বারা ব্যবহৃত হতে পারে এবং আপনার API থেকে আরও কার্যকারিতা সরবরাহ করতে পারে,
  • অ্যাপ্লিকেশন টোকেন : টোকেন যা প্রকৃতপক্ষে অ্যাপ্লিকেশনগুলির মধ্যে সংরক্ষণ করা হবে এবং কেবলমাত্র আপনার ক্রিয়াকলাপগুলিতে আপনার অ্যাপ্লিকেশনটিতে সীমিত অ্যাক্সেস থাকবে যা আপনার বা অ্যাপ্লিকেশন প্রোগ্রামারের ডেটাকে কলুষিত করতে পারে না।

তবে কেউ কী সোর্স কোডটি ডিকনস্ট্রাক্ট করে, অ্যাপ্লিকেশনটি থেকে টোকেনগুলি নিয়ে যায়, পাবলিক এন্ডপয়েন্টগুলি কী এবং আপনার ওয়েব পরিষেবাটিকে অপব্যবহার করে তা খুঁজে পায়?

আপনি যদি আপনার অ্যাপ্লিকেশনটি গ্রাস করে এমন অ্যাপ্লিকেশনগুলির বিকাশ সরাসরি পরিচালনা না করেন তবে কিছুই অ্যাপ্লিকেশন থেকে সরাসরি আপনার API কে একইভাবে ব্যবহার করতে বাধা দেয় না।


এখনও পর্যন্ত ভাল ব্যাখ্যা, আমি যদিও একটি প্রশ্ন। আসুন ধরা যাক যে আমার এপিআইয়ের একটি হ'ল আমার ব্যবহারকারীর সম্পর্কিত সমস্ত ডেটা (এ + বি) আনার জন্য । আমার ব্যবহারকারী কেবল তার ব্যবহারকারীরfiltered data (বি) পেতে এই অ্যাপ্লিকেশনটিকে এই অ্যাপ্লিকেশনটিতে ব্যবহার করে । এখন এটি সম্ভব, বা তৃতীয় ব্যবহারকারীর দ্বারা আমার ব্যবহারকারীর সমস্ত ডেটা (এ + বি) চুরি করতে বাধা দেওয়ার মতো কোনও কার্যকারিতা রয়েছে ? এটা বোঝা যায় না?
অলোক প্যাটেল

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

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

আপনি কি আপনার এই বিষয়টি আমাকে ব্যাখ্যা করতে পারেন? আপনি যদি নিজের অ্যাপ্লিকেশনটি গ্রাস করে অ্যাপ্লিকেশনগুলির সরাসরি বিকাশ না করেন
অলোক প্যাটেল

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

5

আপনার সমস্যাটি কোনও ব্যবসায়িক হিসাবে তেমন প্রযুক্তিগত নয়।

আসুন আপনাকে বলি যে আপনার এপিআই রয়েছে যা আপনি আপনার গ্রাহকদের (অ্যাপ্লিকেশন বিকাশকারীদের) এক বছরে £ 100, সীমাহীন অ্যাক্সেসের ফ্ল্যাট রেটে বিক্রি করেন।

ঠিক আছে, তবে স্পষ্টতই, আমি আপনার পরিষেবাটি 100 ডলারে কিনতে এবং এটি প্রতি 10 ডলারে 50 ডলারে বিক্রয় করতে পারি। আপনি এটা চান না! সুতরাং আপনি এমন কোনও বিধিনিষেধের কথা ভাবার চেষ্টা করবেন যা সালিশের জন্য উন্মুক্ত না হয়ে আপনার এপিআই বিক্রি করতে দেয়।

  • আপনি যদি কেবল অ্যাপ্লিকেশনের সংখ্যাকে সীমাবদ্ধ করেন তবে কোনও গ্রাহক একটি একক অ্যাপ্লিকেশন তৈরি করতে পারবেন যা অন্যান্য অ্যাপ্লিকেশন থেকে সংযোগ গ্রহণ করে এবং সেগুলিতে চলে যায়।

  • আপনি যদি ব্যবহারকারীদের সীমাবদ্ধ করেন, আবারও, গ্রাহক তার নিজস্ব প্রমাণীকরণের পিছনে ব্যবহারকারীদের আড়াল করতে পারেন এবং একক ব্যবহারকারী হিসাবে উপস্থিত হতে পারে।

আপনাকে যা করতে হবে তা হ'ল প্রতিটি গ্রাহকের কাছে এপিআই কলটির মূল্য প্রদান করা। অর্থাত্ পিপিআই কল প্রতি চার্জ করুন বা প্রতি বছর কলের একটি কোটা সেট করুন।

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


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

ব্যবসায়ের দৃষ্টিকোণ থেকে, সমস্যাটি সমাধানযোগ্য নয়। দুঃখের বিষয়, আপনি এটি প্রোগ্রাম থেকেও সমাধান করতে পারবেন না।
অ্যান্ডি

1
ব্যবসায়ের সমস্যা .এক কল প্রতি চার্জ করে সমাধান করা হয়। কীটি চুরি হয়ে গেলে আপনার গ্রাহক হারাবেন। তুমি না. কেবলমাত্র আপনার গ্রাহককে চুরি করা কীগুলি বাতিল করার উপায় দিন এবং তাদের আপত্তি রোধ করার জন্য একটি মধ্যবর্তী এপি দেওয়ার কথা বলুন
ইওয়ান

2

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

এটা নিশ্চিত.

দুটি নীতি (বাস্তবায়নের বিশদটি অনুসরণ করবে):

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

প্রদত্ত যে, যদি ক্লায়েন্ট শংসাপত্রগুলির সাথে প্রমাণীকরণের শেষ পয়েন্টটিতে একটি অনুরোধ করে এবং সার্ভার এটি প্রমাণীকরণ করে তবে সার্ভারটি একটি গতিশীল অস্থায়ী তৈরি করতে পারে টোকেন (অস্থায়ী অর্থ সময় ভিত্তিক)। এই টোকেনটি ক্লায়েন্টের মধ্যে মনে রাখা উচিত এবং পরবর্তী অনুরোধগুলির সাথে প্রেরণ করা উচিত।

আপনার টোকেন পর্যায়ক্রমে "রিফ্রেশ" করার জন্য একটি প্রক্রিয়া প্রয়োজন, যার অর্থ, একটি নতুন পেতে। শংসাপত্রগুলি থেকে পুনরায় প্রমাণীকরণ করা এড়াতে কেবল একটি REST এন্ডপয়েন্টটি তৈরি করুন যা বিদ্যমান থেকে নতুন টোকেন তৈরি করার অনুমতি দেয়।

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

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


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

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

যাইহোক, ওআউথের মতো এটিকে আরও সহজ করে তুলতে সহায়তা করার মানদণ্ড রয়েছে।
ব্র্যান্ডন

0

যদি আপনার প্রতি অ্যাপ্লিকেশন কীগুলি অনন্য থাকে তবে আপনি কেবল ক্লায়েন্ট দ্বারা সূচিত প্রাথমিক সংযোগ প্রমাণীকরণের সময় সেগুলি ব্যবহার করতে পারেন, তার পরে আপনি প্রতি অ্যাপ্লিকেশন অনন্য প্রমাণীকরণ টোকনে রোলিং করতে চলেছেন।

আপনার সার্ভার সময় সময় প্রতিটি ক্লায়েন্ট অ্যাপ্লিকেশন জন্য টোকেন পরিবর্তন (রোলস) (পর্যায়ক্রমে প্লাস / মাইনাস কিছু এলোমেলো अस्पष्ट / এলোমেলো বিলম্ব, উদাহরণস্বরূপ)। রোলিং টোকেনটি কেবলমাত্র সার্ভার এবং প্রমাণীকৃত ক্লায়েন্টের মধ্যেই পরিচিত।

নতুন টোকেনগুলি নিয়মিত জবাবগুলিতে পিগির ব্যাকযুক্ত ফিরে আসে। যখনই জবাবটিতে একটি নতুন টোকেন থাকে তখন প্রাপ্তি অ্যাপ্লিকেশনটিকে পরবর্তী অনুরোধগুলিতে এটি ব্যবহার করে স্যুইচ করা প্রয়োজন।

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

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

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

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


0

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

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


জাভাস্ক্রিপ্ট জন্য প্রায় কাজ কি? কিভাবে এটির জন্য স্থপতি?
অলোক প্যাটেল

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

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

0

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

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

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

এটি আপনার প্রশ্নের ক্ষেত্র থেকে সামান্য বিভ্রান্ত হতে পারে তবে এটি আপনার টোকেনের সুরক্ষার সাথে সম্পর্কিত তাই আমি এটি উল্লেখ করব। তারের উপর দিয়ে টোকেনের তুচ্ছ চুরি রোধ করতে আপনি সম্ভবত সরাসরি টোকেনটি প্রেরণ করতে চান না, পরিবর্তে আপনি এইচএমএসি ফাংশন ব্যবহার করে ট্র্যাফিকটিতে স্বাক্ষর করতে পারেন। আপনি সার্ভারে বার্তাটির HMAC গণনা করে এবং ক্লায়েন্টের কাছ থেকে প্রেরিত HMAC এর সাথে তুলনা করে বার্তাটির বৈধতা পরীক্ষা করতে পারেন। আপনি এইচএমএএসি ফাংশনের মূল হিসাবে টোকেনটি ব্যবহার করবেন যাতে টোকেন জানেন এমন কেউই ট্র্যাফিকে স্বাক্ষর করতে পারে। এটি আপনার টোকেনের সুরক্ষার জন্য আরও ভাল কারণ আপনি এটি কখনই সরাসরি সার্ভারে প্রেরণ করেন না এটি সরাসরি বাধা দেওয়া এবং চুরি করা যায় না। এইচএমএসিএস সম্পর্কিত আরও তথ্যের জন্য এই প্রশ্নটি দেখুন: /security/20129/how-and-when-do-i-use-hmac/20301

কোনও সুরক্ষা সমাধান দুর্ভেদ্য হতে পারে না, আপনাকে সিদ্ধান্ত নিতে হবে যে আপস করার সম্ভাবনা এবং ব্যয় বনাম বাস্তবায়নে আপনার পক্ষে কত ব্যয় হবে।


আমি একটি গ্রন্থাগার তৈরি করতে পারি না এবং এতে গোপনীয়তা রাখতে পারি না, সেগুলি আমার প্রতিটি ব্যবহারকারীর জন্য আলাদা হবে।
অলোক প্যাটেল

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

0

নিজেকে উদ্ধৃত:

আমি কীভাবে ক্লায়েন্ট / ব্যবহারকারীকে প্রমাণীকরণ করব তা নির্ধারণ করতে অক্ষম ... যাতে তারা প্রমাণীকরণের জন্য তাদের ব্যবহারকারীর নাম এবং পাসওয়ার্ড রাখতে পারবেন না।

এখন যে কিছুটা দ্বন্দ্ব, তাই না? ;)

অন্যরা যেমন বলেছে, আপনি পারবেন না। যদি কোনও অ্যাপ্লিকেশন কোনও এপিআই কী ব্যবহার করে, আপনি কী (গুলি) পেতে এবং এটি ব্যবহার করতে বলছেন এমনভাবে এটি কেটে ফেলতে পারে।

অতিরিক্ত যথাযথ ব্যবহারকারীর প্রমাণীকরণের প্রয়োজন ব্যতীত, আপনি কেবল ক্ষতির সীমাবদ্ধ করতে পারেন:

  • শ্বেত তালিকা / কালো তালিকাভুক্ত আইপি
  • থ্রোটলিং
  • "অস্বাভাবিক ক্রিয়াকলাপ" সনাক্তকরণ এবং এর উত্স
  • সহজ কী নবায়ন
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.