জেডাব্লুটি টোকেনগুলির সার্ভার-সাইড হ্যান্ডলিংয়ের সেরা অনুশীলনগুলি [বন্ধ]

Question

( এই থ্রেড থেকে উদ্ভূত হওয়ায় এটি সত্যই নিজের নিজস্ব একটি প্রশ্ন এবং নোডজেএস ইত্যাদির সাথে নির্দিষ্ট নয়)

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

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

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

এটি আমার কাছে প্রশ্ন নিয়ে আসে:

1) জেডাব্লুটি টোকেন বৈধতা কেবলমাত্র টোকেনের স্বাক্ষর যাচাই করা, একা সার্ভারের গোপনীয়তার অখণ্ডতার উপর নির্ভর করে বা পৃথক বৈধকরণের প্রক্রিয়া সহ সীমাবদ্ধ হওয়া উচিত?

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

• সার্ভারটি বর্তমানে সমস্ত টোকেনকে একটি মেমক্যাচে বা অনুরূপ ব্যবহারে রাখার জন্য এটি কল্পনা করতে পারে, এমনকি সার্ভারের গোপনীয়তা আপস করা হলেও যাতে কোনও আক্রমণকারী "বৈধ" টোকেন তৈরি করতে পারে, কেবলমাত্র লগইন শেষের পয়েন্টের মাধ্যমে তৈরি করা টোকেনগুলি গ্রহণ করা হবে। এটি কি যুক্তিসঙ্গত বা কেবল অতিরিক্ত কাজ / অতিরিক্ত কাজ?

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

সার্ভার সিক্রেট আপোস হওয়ার ঝুঁকি নিয়ে আসতে পারে তখন আমি কেবল অতিরিক্ত মাত্রায় বেহাল হয়ে যাচ্ছি, যা অবশ্যই আরও সাধারণ সমস্যা যা সকল ক্রিপ্টোগ্রাফিক পরিস্থিতিতে সমাধান করা প্রয়োজন ...

Comments

দুর্দান্ত প্রশ্ন আছে। পুনরায়: প্রশ্ন 2. আমার কোনও গোপন কীগুলি সার্ভারের পাশে রাখার সাথে একই সমস্যা রয়েছে। যদি আপনি কোনও ধরণের হ্যাশ ম্যাচ বা অসমমিতিক ডিক্রিপশন করছেন, - এটি ডিবিতে সঞ্চিত jwt বা ডিক্রিপটিং সিসি তথ্যের সাইন ইন করছে, আপনার সার্ভারে কোড দ্বারা অ্যাক্সেসযোগ্য একটি গোপন কী থাকতে হবে। তাহলে তুমি কোথায় রেখো ?? এখানে আমি খুঁজে পেয়েছি সেরা উত্তর: pcinetwork.org/forum/index.php?threads/… - সম্ভবত একটি jwt কী জন্য এটি নিরাপদ হিসাবে।

— jbd

JWT টোকেনের গোপন কী কী? আমি jwt টোকেন নিজেকে একটি গোপন চিন্তা করছি। বা গোপন কী কী হতে পারে RSAPrivateKey privateKey??

— কিট্টু

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

— নেলসন রদ্রিগেজ

Answer 1

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

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

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

আপনার প্রশ্নের জন্য:

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

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

Comments

দ্বিতীয় দফার জন্য এখানে একটি উত্তরের উত্তর: সিকিউরিটি.স্ট্যাকেক্সেঞ্জার

— কুইকশানস

টোকেনগুলি শিরোনামে উপলভ্য থাকায়, যদি টোকেনটি চুরি হয়ে যায় এবং কোনও ক্ষতিকারক ব্যক্তি সেই টোকেনটি (ব্যবহারকারীর ইমেল ঠিকানা সম্পর্কে সচেতন থাকা) দিয়ে লগইন করার চেষ্টা করে তবে কী হবে?

— কিট্টু

আপনি যদি প্রতিটি জেডব্লিউটি সঞ্চয় করে থাকেন তবে জেডাব্লুটিটির কোনও লাভ নেই এবং আপনি এলোমেলো সেশন আইডির পাশাপাশি থাকতে পারেন।

— কলিনম

Answer 2

আপনার আবেদনে জেডব্লিউটি প্রয়োগ করার সময় এখানে কয়েকটি বিষয় বিবেচনা করতে হবে:

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

• আপনার জেডাব্লুটিটিতে অনুরোধের url সহ বিবেচনা করুন। উদাহরণস্বরূপ, আপনি যদি চান যে আপনার জেডাব্লুটিটি শেষ পয়েন্টে ব্যবহার করা হয় তবে আপনার জেডাব্লুটিটির /my/test/pathমতো একটি ক্ষেত্র অন্তর্ভুক্ত করুন 'url':'/my/test/path'এটি নিশ্চিত করার জন্য যে এটি কেবল এই পথেই কখনও ব্যবহৃত হয়নি used যদি আপনি এটি না করেন তবে আপনি দেখতে পাবেন যে লোকেরা আপনার শেষ প্রান্তে আপনার জেডাব্লুটিটি ব্যবহার শুরু করে, এমনকি তাদের জন্য তৈরি করা হয়নি। আপনি পরিবর্তে একটি এমডি 5 (ইউআরএল) অন্তর্ভুক্ত করার বিষয়েও বিবেচনা করতে পারেন, কারণ জেডব্লিউটিতে একটি বড় ইউআরএল থাকার ফলে জেডব্লিউটি এত বড় হয়ে যায়, এবং তারা বেশ বড় হতে পারে।

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

• নির্দিষ্ট সময়ের পরে কেবল জেডাব্লুটিটির মেয়াদ শেষ হওয়ার পরিবর্তে, জেডব্লিউটিগুলি বাস্তবায়ন বিবেচনা করুন যা উভয়কে সমর্থন করে:

  • এন ব্যবহার - মেয়াদ শেষ হওয়ার আগেই কেবল এন বার ব্যবহার করা যেতে পারে এবং
  • নির্দিষ্ট সময়ের পরে মেয়াদ শেষ হয়ে যায় (যদি আপনার একটি মাত্র টোকেন ব্যবহার করে থাকে তবে আপনি যদি ব্যবহার না করেন তবে এটি চিরকাল বেঁচে থাকতে চান না, আপনি কি?)

• সমস্ত JWT প্রমাণীকরণ ব্যর্থতা একটি "ত্রুটি" প্রতিক্রিয়া শিরোনাম উত্পন্ন করা উচিত যা JWT প্রমাণীকরণ কেন ব্যর্থ হয়েছে তা উল্লেখ করে। উদাহরণস্বরূপ "মেয়াদোত্তীর্ণ", "কোনও ব্যবহার বাকি নেই", "প্রত্যাহারযোগ্য" ইত্যাদি This এটি প্রয়োগকারীরা তাদের JWT কেন ব্যর্থ হচ্ছে তা জানতে সহায়তা করে।

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

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

• JWT গুলি লগ ফাইলগুলিতে লগ ইন করা উচিত নয়। একটি JWT এর বিষয়বস্তু লগ করা যেতে পারে, তবে নিজেই JWT নয়। এটি ডিভস বা অন্যরা লগ ফাইলগুলি থেকে জেডব্লিউটি'র গ্রাহ্য করতে এবং অন্যান্য ব্যবহারকারীর অ্যাকাউন্টগুলিতে কিছু করতে পারে না তা নিশ্চিত করে।
• নিশ্চিত করুন যে আপনার জেডাব্লুটি বাস্তবায়ন হ্যাকারদের স্বাক্ষর না করে টোকেন তৈরি এড়াতে "কিছুই নয়" অ্যালগোরিদমকে মঞ্জুরি দেয় না। আপনার JWT এর "শিরোনাম" উপেক্ষা করে এই শ্রেণীর ত্রুটিগুলি সম্পূর্ণরূপে এড়ানো যায়।
• আপনার জেডব্লিউটিগুলিতে (মেয়াদোত্তীকরণের) iatপরিবর্তে (জারি করা) ব্যবহারের বিষয়ে expদৃ consider়তার সাথে বিবেচনা করুন। কেন? যেহেতু iatমূলত জেডাব্লুটিটি কখন তৈরি করা হয়েছিল তার অর্থ এটি তৈরির তারিখের ভিত্তিতে জেডাব্লুটিটির মেয়াদ শেষ হওয়ার সাথে সাথে আপনাকে সার্ভারে সামঞ্জস্য করতে দেয়। যদি কেউ expভবিষ্যতে 20 বছর কেটে যায় তবে জেডাব্লুটিটি মূলত চিরকাল বেঁচে থাকে! নোট করুন যে আপনি JWT গুলি iatভবিষ্যতে থাকলে তা স্বয়ংক্রিয়ভাবে মেয়াদোত্তীর্ণ হয়ে যান , তবে ক্লায়েন্টের সময়টি সার্ভারের সময়ের সাথে সামঞ্জস্য হওয়ার বাইরে থাকলে কিছুটা উইগল রুম (উদাহরণস্বরূপ 10 সেকেন্ড) এর জন্য অনুমতি দিন।
• জেসন পেডলোড থেকে জেডব্লিউটি তৈরির জন্য একটি এন্ডপয়েন্ট কার্যকর করার বিষয়টি বিবেচনা করুন এবং আপনার সমস্ত প্রয়োগকারী ক্লায়েন্টকে তাদের জেডব্লিউটি তৈরি করতে এই শেষ পয়েন্টটি ব্যবহার করতে বাধ্য করুন। এটি নিশ্চিত করে যে কীভাবে JWT গুলি সহজেই এক জায়গায় তৈরি করা হয় তার সাথে আপনি যে কোনও সুরক্ষা সমস্যাগুলি সমাধান করতে পারেন। আমরা আমাদের অ্যাপ্লিকেশনটিতে এটি সরাসরি করিনি, এবং এখন আমাদের ধীরে ধীরে জেডাব্লুটি সার্ভারের সাইড সিকিউরিটি আপডেটগুলি ছড়িয়ে দিতে হবে কারণ আমাদের 5 টি বিভিন্ন ক্লায়েন্টকে বাস্তবায়নের জন্য সময় প্রয়োজন। এছাড়াও, আপনার তৈরি এন্ডপয়েন্টটি জেএসডাব্লিউটিগুলি তৈরির জন্য জসন পেডলোডগুলির একটি অ্যারে গ্রহণ করতে দিন এবং এটি আপনার ক্লায়েন্টদের জন্য এই শেষ পয়েন্টে আসা # টি অনুরোধের কমবে।
• আপনার জেডাব্লুটিটি যদি শেষ পয়েন্টগুলিতে ব্যবহার করা হয় যা অধিবেশন দ্বারা ব্যবহারকে সমর্থন করে, তবে নিশ্চিত করুন যে আপনি অনুরোধটি সন্তুষ্ট করার জন্য প্রয়োজনীয় আপনার জেডাব্লুটিটিতে কিছু রাখবেন না। আপনি যদি নিশ্চিত হন যে আপনার শেষ পয়েন্টটি কোনও সেশনের সাথে কাজ করে তবে আপনি কোনও জেডব্লিউটি সরবরাহ না করে সহজেই এটি করতে পারেন।
• সুতরাং জেডাব্লুটিটির সাধারণভাবে বক্তৃতাটি কোনওরকমের ইউজারআইডি বা গ্রুপআইড যুক্ত করে এবং এই তথ্যের উপর ভিত্তি করে আপনার সিস্টেমের অংশে অ্যাক্সেসের অনুমতি দেয়। নিশ্চিত হয়ে নিন যে আপনি আপনার অ্যাপ্লিকেশনটির একটি ক্ষেত্রে ব্যবহারকারীদের অন্য ব্যবহারকারীদের ছদ্মবেশ তৈরি করতে দিচ্ছেন না, বিশেষত যদি এটি সংবেদনশীল ডেটাতে অ্যাক্সেস সরবরাহ করে। কেন? আপনার জেডব্লিউটি প্রজন্মের প্রক্রিয়াটি কেবলমাত্র "অভ্যন্তরীণ" পরিষেবাগুলিতে অ্যাক্সেসযোগ্য থাকলেও ডেভস বা অন্যান্য অভ্যন্তরীণ দলগুলি যে কোনও ব্যবহারকারীর ডেটা অ্যাক্সেস করার জন্য জেডাব্লুটি তৈরি করতে পারে, যেমন কয়েকটি র্যান্ডম ক্লায়েন্টের কোম্পানির সিইও। উদাহরণস্বরূপ, যদি আপনার অ্যাপ্লিকেশন ক্লায়েন্টদের জন্য আর্থিক রেকর্ডগুলিতে অ্যাক্সেস সরবরাহ করে তবে জেডাব্লুটিটি উত্পন্ন করে কোনও দেব কোনও সংস্থার আর্থিক রেকর্ডটি দখল করতে পারে! এবং যদি কোনও হ্যাকার যাইহোক আপনার অভ্যন্তরীণ নেটওয়ার্কে প্রবেশ করে তবে তারাও তা করতে পারে।
• আপনি যদি কোনও ইউআরএল যা কোনও জেডাব্লুটিটি কোনও উপায়ে ক্যাশে যাওয়ার অনুমতি দিতে যাচ্ছেন, তা নিশ্চিত করুন যে বিভিন্ন ব্যবহারকারীর জন্য অনুমতিগুলি ইউআরএলে অন্তর্ভুক্ত রয়েছে, এবং জেডাব্লুটিটি নয়। কেন? কারণ ব্যবহারকারীরা তাদের থাকা উচিত ডেটা শেষ করতে পারে। উদাহরণস্বরূপ, বলুন কোনও সুপার ব্যবহারকারী আপনার অ্যাপ্লিকেশনটিতে লগইন করে এবং নিম্নলিখিত ইউআরএলটির জন্য অনুরোধ করে: /mysite/userInfo?jwt=XXXএবং এই urlটি ক্যাশে হয়ে যায়। তারা লগআউট করে এবং কয়েক মিনিট পরে, নিয়মিত ব্যবহারকারী আপনার অ্যাপ্লিকেশনটিতে লগইন করে। তারা ক্যাশযুক্ত সামগ্রী পাবে - একটি সুপার ব্যবহারকারী সম্পর্কে তথ্য সহ! এটি ক্লায়েন্টের উপর কম ঘটবে এবং সার্ভারে আরও ঘটবে cases বিশেষত আপনি যেখানে আকামাইয়ের মতো সিডিএন ব্যবহার করছেন এবং কিছু ফাইল দীর্ঘায়িত হতে দিচ্ছেন। এটি ইউআরএলে প্রাসঙ্গিক ব্যবহারকারীর তথ্য অন্তর্ভুক্ত করে এবং এটি সার্ভারে বৈধ করে এমনকি ঠিক করা অনুরোধগুলির জন্যও ঠিক করা যেতে পারে, উদাহরণস্বরূপ/mysite/userInfo?id=52&jwt=XXX
• যদি আপনার জাডব্লিউটিটি সেশন কুকির মতো ব্যবহারের উদ্দেশ্যে হয় এবং কেবল একই মেশিনে কাজ করা উচিত যদি ডাব্লুডাব্লুটি তৈরি করা হয়েছিল, তবে আপনার jwt এ একটি জেটি ফিল্ড যুক্ত করার কথা বিবেচনা করা উচিত । এটি মূলত একটি সিএসআরএফ টোকেন, এটি নিশ্চিত করে যে আপনার জেডাব্লুটিটি একজন ব্যবহারকারীর ব্রাউজার থেকে অ্যানেরসে যেতে পারে না।

Comments

আপনি যা উল্লেখ করেন created_by, জেডাব্লুটিটিতে এর জন্য ইতিমধ্যে একটি দাবি রয়েছে এবং এটি iss(ইস্যুকারী) বলে।

— ফ্রেড

হ্যাঁ ভাল পয়েন্ট - আমি যে সাথে আপডেট করব ... ধন্যবাদ!

— ব্র্যাড পার্কগুলি

Answer 3

আমি মনে করি না যে আমি একজন বিশেষজ্ঞ তবে আমি Jwt সম্পর্কে কিছু ধারণা ভাগ করতে চাই।

• 1: অক্ষয় যেমন বলেছিলেন, আপনার টোকেনকে বৈধতা দেওয়ার জন্য দ্বিতীয় সিস্টেম থাকা ভাল।

  a .: যেভাবে আমি এটি পরিচালনা করি: আমি কাটা কাটা সময়ের সাথে একটি সেশন স্টোরেজে জেনারেট হ্যাশ সংরক্ষণ করি। একটি টোকেন যাচাই করতে এটি সার্ভার দ্বারা জারি করা দরকার।

  বি .: এখানে কমপক্ষে একটি জিনিস রয়েছে যা অবশ্যই স্বাক্ষর পদ্ধতিটি ব্যবহার করা উচিত checked যেমন:

  header :
  {
    "alg": "none",
    "typ": "JWT"
  }
  

জেডাব্লুটিটি যাচাই করে কিছু গ্রন্থাগার হ্যাশ যাচাই না করেই এটি গ্রহণ করবে। এর অর্থ হ'ল টোকেনে স্বাক্ষর করতে আপনার লবণ ব্যবহার না করে, একজন হ্যাকার নিজেকে কিছু অধিকার দিতে পারে। সর্বদা নিশ্চিত করুন যে এটি ঘটতে পারে না। https://auth0.com/blog/2015/03/31/critical-vulnerabilities-in-json-web-token-libraries/

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

• 2: প্রতিটি গোপনীয়তার জন্য এটি একই রকম। এটি সর্বদা জানার উপায় আছে।

আমি যেভাবে এটি পরিচালনা করি সেটি পয়েন্ট ১ এ এর ​​সাথে যুক্ত। : আমার একটি এলোমেলো ভেরিয়েবলের সাথে একটি গোপন মিশ্রণ রয়েছে। গোপনীয় প্রতিটি টোকেনের জন্য অনন্য।

তবে, টোকনকে কীভাবে এবং কতটা পরিমাণে কার্যকর করা উচিত, সত্যিকারের সুরক্ষিত সিস্টেম তৈরি করার জন্য আমি সর্বোত্তম অনুশীলনগুলি বোঝার চেষ্টা করছি।

আপনি যদি সেরা সেরা সুরক্ষা চান তবে আপনার অন্ধভাবে সেরা অভ্যাসগুলি অনুসরণ করা উচিত নয়। আপনি কী করছেন তা বোঝার সর্বোত্তম উপায় হ'ল (আপনার প্রশ্নটি আমি যখন দেখি তখন ঠিক হয়ে যায়), এবং তারপরে আপনার প্রয়োজনীয় সুরক্ষাটি মূল্যায়ন করুন। এবং যদি মোসাদ আপনার গোপনীয় ডেটাতে অ্যাক্সেস পেতে চায় তবে তারা সর্বদা একটি উপায় খুঁজে পাবে। (আমি এই ব্লগ পোস্টটি পছন্দ: https://www.schneier.com/blog/archives/2015/08/mickens_on_secu.html )

Comments

প্রতিটি টোকেনের জন্য একটি অনন্য গোপন থাকার জন্য ভাল পয়েন্ট তবে আপনি কীভাবে প্রতিবার একটি অনন্য গোপন তৈরি করবেন? আমি নিম্বাস jwt গ্রন্থাগার ব্যবহার করছি

— kittu

সম্ভবত আপনার ব্যবহারকারীর হ্যাশ পাসওয়ার্ড ব্যবহার করুন।

— মোমোকজআআআআআআআআআআআআআআ।

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

— মেনবুয়েরোক

@ মেনবুয়েরোকো আমি আপনার সাথে পুরোপুরি একমত, যে

— ছেলেটি

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

— মেনবুয়েরোক

Answer 4

এখানে অনেক ভাল উত্তর। আমি যে উত্তরগুলিকে সবচেয়ে প্রাসঙ্গিক বলে মনে করি সেগুলির কয়েকটি সংহত করব এবং আরও কিছু পরামর্শ যুক্ত করব।

1) জেডাব্লুটি টোকেন বৈধতা কেবলমাত্র টোকেনের স্বাক্ষর যাচাই করা, একা সার্ভারের গোপনীয়তার অখণ্ডতার উপর নির্ভর করে বা পৃথক বৈধকরণের প্রক্রিয়া সহ সীমাবদ্ধ হওয়া উচিত?

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

অন্যান্য সুরক্ষা ব্যবস্থার মধ্যে জেডাব্লুটিটি লগ না করা এবং SHA256 এর মতো সুরক্ষিত স্বাক্ষরকরণ অ্যালগরিদম প্রয়োজন।

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

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

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

তবে কোনও আপোস করা সার্ভার গোপনের ক্ষয়ক্ষতি হ্রাস করতে এবং উত্স কোডে গোপনীয়তাগুলি সংরক্ষণ করা এড়ানোর জন্য https://zookeeper.apache.org এর মতো সমন্বয় পরিষেবা ব্যবহার করে টোকেন গোপন ঘূর্ণন জড়িত ves। প্রতি কয়েক ঘন্টা বা তার বেশি সময় ধরে অ্যাপের গোপনীয়তা তৈরি করতে ক্রোন জব ব্যবহার করুন (তবে আপনার অ্যাক্সেস টোকেনগুলি এর জন্য কার্যকর) এবং চিড়িয়াখানায় আপডেট হওয়া গোপনীয়তাটি চাপ দিন। প্রতিটি অ্যাপ্লিকেশন সার্ভারে যার টোকেন সিক্রেট জানতে হবে, যখনই জে কে নোডের মান পরিবর্তন হয় তখন একটি জেডকে ক্লায়েন্ট কনফিগার করুন। একটি প্রাথমিক এবং একটি গৌণ গোপন সংরক্ষণ করুন এবং প্রতিবার টোকেন গোপন পরিবর্তন করা হলে প্রাথমিক এবং পুরানো টোকেন গোপনকে গৌণতে নতুন সেট করুন। এইভাবে, বিদ্যমান বৈধ টোকেনগুলি এখনও বৈধ থাকবে কারণ সেগুলি মাধ্যমিক গোপনের বিরুদ্ধে বৈধ করা হবে। গৌণ সিক্রেটটি পুরানো প্রাথমিক গোপনের সাথে প্রতিস্থাপনের সময়, দ্বিতীয় গোপনীয়তার সাথে জারি করা সমস্ত অ্যাক্সেস টোকেনগুলি যেকোনোভাবেই শেষ হয়ে যাবে।

Answer 5

IETF OAuth ওয়ার্কিং গ্রুপ মধ্যে অগ্রগতি একটি জন্য RFC আছে দেখুন: https://tools.ietf.org/id/draft-ietf-oauth-jwt-bcp-05.html