এপিআই প্রমাণীকরণ, এককালীন টোকেন ভিএস ডায়নামিক টোকেন


13

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

প্রথম পরামর্শ: (এককালের টোকেন একে একে স্ট্যাটিক টোকন)

  1. ক্লায়েন্টটি প্রাথমিক টোকেনটির জন্য, ব্যবহারকারী নাম এবং পাসওয়ার্ড এবং বর্তমান_কাল (এই ভেরিয়েবলটি সার্ভারের ডাটাবেসে এবং ক্লায়েন্টের পক্ষে সংরক্ষণ করা হবে) এপিআই-তে অনুরোধ করে, সার্ভারটি ইনপুটটি ব্যাখ্যা করে এবং একটি হ্যাশড টোকেনকে রেন্ডার করে (যেমন: 58f52c075aca5d3e07869598c4d66648) এটি ডাটাবেসে সংরক্ষণ করে এবং ক্লায়েন্টকে ফিরিয়ে দেয়।

  2. ক্লায়েন্ট এখন প্রাথমিক টোকেন সংরক্ষণ করে এবং প্রমাণীকরণের অনুরোধে প্রেরিত প্রাথমিক টোকেন + বর্তমান_কালীন ভেরিয়েবলটি ব্যবহার করে নতুন হ্যাশ টোকেন তৈরি করে (এই নতুন টোকেনটিকে কল করতে দিন, মূল_ টোকেন) একই সার্ভারটিও একই কাজ করে এবং একই অ্যালগরিদম ব্যবহার করে একই টোকেন তৈরি করে ।

  3. প্রতিবার ক্লায়েন্ট সার্ভার এপিআই অনুসন্ধান করে, এটি সার্ভারের সাথে মেইন টোকন প্রেরণ করে, এখন সার্ভার এতে উত্পন্ন টোকেনের সাথে ক্লায়েন্টের প্রেরিত মেইন টোকনটির সাথে তুলনা করে, যদি এটি মেলে তবে এর অর্থ ব্যবহারকারী সত্যই

দ্বিতীয় পরামর্শ: (গতিশীল টোকেন)

  1. ক্লায়েন্ট দুটি এলোমেলো কী তৈরি করে ($ কী 1 = র‌্যান্ড (10000,90000); $ কী 2 = র‌্যান্ড (10000,90000);) API তে প্রতিটি অনুরোধে ক্লায়েন্টটি কোয়েরি টাইপ ব্যবহার করে একটি হ্যাশ তৈরি করে, এবং দুটি কী দিয়ে একটি জটিল অ্যালগরিদম এবং সার্ভারে এই দুটি কী + হ্যাশ প্রেরণ করে

  2. সার্ভার, ক্লায়েন্টে ব্যবহৃত একই অ্যালগরিদম ব্যবহার করে একটি হ্যাশ তৈরি করে এবং ক্লায়েন্টের প্রেরিত সাথে তুলনা করা হয়, যদি এটি মেলে, সার্ভারটি কোয়েরিটি মোকাবেলা করতে এগিয়ে যায়


এখন, প্রশ্নটি হল, এপিআই অনুরোধগুলি সুরক্ষিত করার জন্য কোনটি সবচেয়ে যুক্তিসঙ্গত এবং সুরক্ষিত উপায়?


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

1
হতে পারে আমি কিছু মিস করছি ... তবে কেন OAuth প্রমাণীকরণ প্রক্রিয়া হিসাবে ব্যবহার করবেন না? এটি স্ট্যান্ডার্ড এবং আপনার ক্লায়েন্টদের প্রায় প্রতিটি ভাষায় ব্যবহার করার জন্য গ্রন্থাগার থাকবে।
Icode4food

উত্তর:


14

আমি সত্যিই সাধারণভাবে প্রথম পদ্ধতি পছন্দ করি।

  • এটি বুঝতে এবং বাস্তবায়ন করা সহজ
  • এটি নিরাপদ (আমার জ্ঞানের কাছে)
  • এটি একটি অস্বাভাবিক পদ্ধতি নয় যা আমি অতীতে ব্যবহার করেছি

একটি জিনিস আমি প্রথমে উল্লেখ করতে দেখছি না যা আপনার মনে রাখা উচিত, টোকেনটি হ্যাশ করার জন্য ব্যবহৃত টাইমস্ট্যাম্পটির একটি টিটিএল সমাপ্তি হওয়া দরকার যা অত্যন্ত সংক্ষিপ্ত (1 সেকেন্ডের মতো) যাতে আপনি বার্তাটি প্রেরণ করা হয়নি তা যাচাই করে নিন 12 ঘন্টা আগে একটি বার্তা থেকে একই টাইমস্ট্যাম্প এবং টোকেন; স্পষ্টতই এটি বৈধ হিসাবে গণনা করা হবে তবে এই ক্ষেত্রে নয়।

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

নোট না, আমি না একটি নিরাপত্তা বিশেষজ্ঞ।


OAuth এর / ফেডারেটেড

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

প্রো:

  • স্ট্যান্ডার্ড ভিত্তিক
  • সমস্যাগুলি অন্যের সিস্টেমে অন্যরা খুঁজে পাবেন যাতে আপনি নিরাপত্তাহীনতা ঘটে কিনা তা খুঁজে পেতে পারেন
  • আপনার দ্বারা অনেক কম লেখকের কাজ প্রয়োজন হবে

কন:

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

অ্যাসিঙ্ক্রোনাস শংসাপত্র

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

নভেল থেকে (হ্যাঁ আমি জানি, উপন্যাস? সত্যই?)

এককালের পাসওয়ার্ড তৈরি করতে টোকনগুলি ভিত্তি হিসাবে একটি ভেরিয়েবল ব্যবহার করে। এই পরিবর্তনশীল চ্যালেঞ্জ বলা হয়। পাসওয়ার্ড তৈরি করতে ব্যবহৃত ভেরিয়েবল নির্ধারণের জন্য দুটি প্রধান পদ্ধতি হ'ল অ্যাসিনক্রোনাস বা সিঙ্ক্রোনাস।

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

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

প্রো:

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

কন:

  • শংসাপত্রগুলি প্রোগ্রামিয়মে কাজ করার জন্য কৌশলযুক্ত হতে পারে
  • আপনার যদি বাহ্যিক সিএ প্রয়োজন হয় তার উপর নির্ভর করে বিনামূল্যে থাকতে পারে না
  • প্রত্যাশিত রুট ট্রাস্টগুলি কনফিগার করা আছে তা নিশ্চিত করতে ম্যানুয়ালি শংসাপত্রের স্টোরগুলি বজায় রাখতে হবে May

করা NTLM

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

প্রো:

  • কনফিগার করা, প্রয়োগ করা এবং রক্ষণাবেক্ষণ করা অত্যন্ত সহজ

কন:

  • নূন্যতম আন্তঃব্যবযোগিতা
  • জনসাধারণের মুখোমুখি প্রমাণীকরণের জন্য পর্যাপ্ত নয়

Nonces

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

প্রো:

  • থওয়ার্টস আক্রমণগুলি বেশ ভালভাবে রিপ্লে করে
  • বাস্তবায়ন বা বুঝতে মোটেও কঠিন নয়

কন:

  • ক্লায়েন্টদের প্রতিটি অনুরোধের জন্য দুটি অনুরোধ করা প্রয়োজন (যদিও কেবলমাত্র কিছু নির্দিষ্ট অনুরোধের জন্য ননস প্রয়োজনের মাধ্যমে কমিয়ে দেওয়া যেতে পারে )
  • নোনেস পরিচালনা প্রয়োজন, যা লেনদেনের হওয়া উচিত
  • নেরেটিভভাবে ননসেসের জন্য অতিরিক্ত অনুরোধের প্রয়োজনের দ্বারা কর্মক্ষমতাকে প্রভাবিত করে (লেনদেনের ফলে ননসের সাথে কাজ করার জন্য রিসোর্স ব্যয় আরও বাড়ায়)

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

1
আপনি কারবেরোস ভুলে গেছেন । এবং আমি আপনার নিজের প্রমাণীকরণ / টোকেন প্যাকেজটি প্রশ্নের উত্সাহের মতো ঘুরিয়ে দেওয়ার বিরুদ্ধে একটি ব্যতিক্রমী কঠোর সতর্কতা রেখেছি। RYO auth ভুল হওয়া খুব সহজ; উদাহরণস্বরূপ, কেবলমাত্র ৮০,০০০ সংখ্যা বিশিষ্ট সংখ্যার মান (অপির ২ য় ক্ষেত্রে) থেকে একটি সিডিং কী স্পেস ব্যবহার করা হবে। আপনি কী হ্যাশগুলি ব্যবহার করছেন সে সম্পর্কে আপনাকে সতর্কতা অবলম্বন করতে হবে (1 ম কেস থেকে)। অনেকেই এখন রেইনবো টেবিলের লুকআপ থেকে তুচ্ছভাবে ভেঙেছেন।

1
উত্তরের সাথে আপনাকে অনেক ধন্যবাদ, আমি সেই প্রকল্প থেকে সরে এসেছি, তবে আমি এই প্রশ্নটি আমার পছন্দসই করে রাখব। দুঃখিত যে আমি আপনার উত্তরটি খুব পুঙ্খানুপুঙ্খভাবে গ্রহণ করেছি বলে গ্রহণ করি নি। তবে, উপন্যাসটি খারাপ হওয়ার কী আছে? :(
সাফাদ

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