জেডব্লিউটি চুরি হলে কী হবে?


201

আমি আমার RESTful APIs এর জন্য JWT এর সাথে রাষ্ট্রবিহীন প্রমাণীকরণ প্রয়োগ করার চেষ্টা করছি।

আফাইক, জেডাব্লুটিটি মূলত একটি এনআরটিএস কলের সময় এইচটিটিপি শিরোনাম হিসাবে পাস করা একটি এনক্রিপ্টযুক্ত স্ট্রিং।

তবে যদি এমন কোনও শ্রবণশক্তি রয়েছে যিনি অনুরোধটি দেখেন এবং টোকেনটি চুরি করেন ? তাহলে সে কি আমার পরিচয় দিয়ে জাল অনুরোধ করতে পারবে?

আসলে, এই উদ্বেগটি সমস্ত টোকেন-ভিত্তিক প্রমাণীকরণের জন্য প্রযোজ্য ।

কীভাবে তা প্রতিরোধ করবেন? এইচটিটিপিএসের মতো সুরক্ষিত চ্যানেল?


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

4
@ জোনাথনরাইনহার্ট তবে যদি একটি টোকেন শীঘ্রই শেষ হয়, তবে আমার ক্লায়েন্টকে সময়ে সময়ে নিজেকে পুনরায় প্রমাণীকরণের মাধ্যমে একটি নতুন টোকেন পেতে হবে। এটা কি একরকম ক্লান্তিকর নয়?
স্মিভিকিপিডিয়া

@ জোনাথনরেইনহার্ট আমি মনে করি টোকেন কেন স্বল্পস্থায়ী? কারণ সেভাবে, সার্ভারটির কোনও টোকেনের মেয়াদ শেষ হওয়ার ট্র্যাক রাখতে হবে না এবং এভাবে স্কেলেবিলিটির জন্য পথ তৈরি করা দরকার। এটা একটা ধরনের trade-offমধ্যে having finer control of token expirationএবং having better scalability
smwikedia

2
এটি কি সাহায্য করতে পারে? - "টোকেন চুরি সনাক্ত করার জন্য একটি সাধারণ সুরক্ষা ব্যবস্থা হ'ল অনুরোধ আইপি ঠিকানার উত্সের উপর নজর রাখা" " - এখানে শেষ বিভাগে বিশদে বর্ণনা করা হয়েছে - firebase.google.com/docs/auth/admin/manage-sessions
উলা

3
তাত্ত্বিকভাবে, টোকেন চুরি রোধ করা অসম্ভব। আমরা যা করতে পারি তা হ'ল এটি ঘটেছে তা সনাক্ত করে এবং তারপরে ASAP সেশনটি বাতিল করে দিন। সনাক্তকরণের সর্বোত্তম পদ্ধতি হ'ল ঘোরানো রিফ্রেশ টোকেন (আরএফসি 6819 দ্বারা প্রস্তাবিত) ব্যবহার করা। এখানে একটি ব্লগ এখানে এটিকে বিশদভাবে ব্যাখ্যা করেছে: সুপারটোকেনস.আইও
পোদ্দার

উত্তর:


284

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

প্রথমত, জেডব্লিউটিগুলি সাধারণত এনক্রিপ্ট করা হয় না । জেডাব্লুটি টি এনক্রিপ্ট করার একটি উপায় রয়েছে (দেখুন: জেডাব্লুই ), এটি অনেক কারণেই বাস্তবে খুব বেশি সাধারণ নয়।

পরবর্তী, প্রমাণীকরণের যে কোনও ফর্ম (JWTs ব্যবহার করুন বা না), MitM আক্রমণগুলির (ম্যান-ইন-দ্য-মিডল) আক্রমণের সাপেক্ষে। আপনি যখন ইন্টারনেটে অনুরোধ করবেন তখন কোনও আক্রমণকারী আপনার নেটওয়ার্ক ট্র্যাফিকটি দেখতে পারে যখন এই আক্রমণগুলি ঘটে। আপনার আইএসপি এটি দেখতে পারে, এনএসএ ইত্যাদি is

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

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

এখন, এখানেই প্রোটোকল আসবে।

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

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

আপনার প্রশ্নটি কী আকর্ষণীয় করে তোলে তা হ'ল প্রোটোকলটি ব্যবহার করা হচ্ছে (সম্ভবত OAuth2)।

OAuth2 যেভাবে কাজ করে তা হ'ল এটি ক্লায়েন্টকে কেবলমাত্র সময়ের শর্ট প্যারিডের জন্য প্রমাণীকরণের জন্য টেম্পোরারি টোকেনগুলি (JWTs এর মতো!) দেওয়ার জন্য ডিজাইন করা হয়েছিল!

ধারণাটি হ'ল যদি আপনার টোকেনটি চুরি হয়ে যায়, আক্রমণকারী কেবলমাত্র অল্প সময়ের জন্য এটি ব্যবহার করতে পারে।

OAuth2- এর সাহায্যে আপনাকে প্রতিবার আপনার ব্যবহারকারী নাম / পাসওয়ার্ড বা এপিআই শংসাপত্র সরবরাহ করে এবং তারপরে বিনিময়ে টোকেন ফিরে পেয়ে সার্ভারের সাথে নিজেকে পুনরায় প্রমাণীকরণ করতে হয়।

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

আশা করি এটি সহায়তা করে ^^


3
নিম্নলিখিত নিবন্ধটির লেখক যুক্তি দেখিয়েছেন যে জেডাব্লুটিটির একটি অসুবিধা হ'ল চুরি হওয়া জেডাব্লুটিটি থেকে পুনরুদ্ধারের একমাত্র উপায় হল একটি নতুন কী-জুড়ি তৈরি করা এবং কার্যকরভাবে সমস্ত ব্যবহারকারীকে লগ আউট করা। যেখানে কোনও ডিবিতে সেশন-আইডিসহ সংরক্ষিত ওয়েবসাইটগুলি কেবল আক্রান্ত ব্যবহারকারীর সেশনগুলি মুছতে পারে এবং তাকে সমস্ত ডিভাইস থেকে লগ আউট করতে পারে। আমি নিশ্চিত নই যে এখানে OAuth2 কীভাবে ছবিতে ফিট করে বা এটি উপস্থাপিত অসুবিধাগুলি প্রশমিত করতে সহায়তা করে কিনা। माध्यम.com
মার্সেল

4
লেখক ভুল। টোকেনকে অবৈধ করতে আপনি বিভিন্ন নকশার নিদর্শন ব্যবহার করতে পারেন। তবে সাধারণভাবে: কোনও ধরণের প্রমাণীকরণের উদ্দেশ্যে JWT ব্যবহার করা একটি খারাপ ধারণা। ক্রিপ্টোগ্রাফিকভাবে স্বাক্ষরিত একটি সেশন আইডির অভ্যন্তরে এমবেড থাকা সেশন কুকিটি ব্যবহার করার চেয়ে এটি আরও দক্ষ far

1
@rdegges দয়া করে বলুন কীভাবে JWT প্রমাণীকরণের জন্য খারাপ ধারণা? এবং উপরের আপনার মন্তব্যে আমি উল্লিখিত সেশন কুকিটি কীভাবে ব্যবহার করতে পারি?
নোমান তুফাইল

6
একক প্রতিক্রিয়া টাইপ করতে এটি বেশ দীর্ঘ। আপনি যদি আরও শিখতে চান তবে আমি এই বিষয়ে একটি বিস্তারিত আলোচনা দিয়েছি। আপনি আমার স্লাইডগুলি অনলাইনে চেক করতে পারেন: স্পিকারডেক.আরডিজেজেস
সাক- এবং-

2
তাত্ত্বিকভাবে, টোকেন চুরি রোধ করা অসম্ভব। আমরা যা করতে পারি তা হ'ল এটি ঘটেছে তা সনাক্ত করে এবং তারপরে ASAP সেশনটি বাতিল করে দিন। সনাক্তকরণের সর্বোত্তম পদ্ধতি হ'ল ঘোরানো রিফ্রেশ টোকেন (আরএফসি 6819 দ্বারা প্রস্তাবিত) ব্যবহার করা। এখানে একটি ব্লগ এখানে এটিকে বিশদভাবে ব্যাখ্যা করেছে: সুপারটোকেনস.আইও
পোদ্দার

31

আমি জানি এটি একটি পুরানো প্রশ্ন তবে আমি মনে করি যে আমি আমার $ 0.50 এখানে ড্রপ করতে পারি, সম্ভবত কেউ আমার পদ্ধতির সম্পূর্ণ অস্বীকার করার জন্য উন্নতি করতে বা যুক্তি সরবরাহ করতে পারে। আমি এইচটিটিপিএস (অফসি) এর মাধ্যমে একটি রেস্টস্টুল এপিআইতে জেডাব্লুটি ব্যবহার করছি।

এটির জন্য কাজ করতে, আপনি সবসময় স্বল্পস্থায়ী টোকেন ইস্যু করা উচিত (বেশিরভাগ ক্ষেত্রেই উপর নির্ভর করে আমার app এর মধ্যে আমি আসলে সেটিং করছি exp30 মিনিট দাবি, এবং ttl3 দিন, তাই আপনি যতদিন পর্যন্ত এই টোকেন রিফ্রেশ করতে তার ttlএখনও বৈধ এবং টোকেন কালো তালিকাভুক্ত করা হয়নি )

জন্য authentication service, বাতিল টোকেন করার জন্য, আমি একটি ইন-মেমোরি ক্যাশে স্তর (ব্যবহার করতে চান redis হিসেবে আমার ক্ষেত্রে) JWT blacklist/ ban-list(আমি এটা RESTful দর্শন ভঙ্গ, কিন্তু সঞ্চিত নথি আছেন: সামনে, কিছু criterias উপর নির্ভর করে সত্যই স্বল্প-কালীন, যেমন আমি তাদের অবশিষ্ট সময় থেকে বাঁচার জন্য কালো তালিকাভুক্ত - ttlদাবি-)

দ্রষ্টব্য: কালো তালিকাভুক্ত টোকেনগুলি স্বয়ংক্রিয়ভাবে সতেজ করা যাবে না

  • যদি user.passwordবা user.emailআপডেট করা হয় (পাসওয়ার্ড নিশ্চিতকরণের প্রয়োজন), প্রমাণীকরণ পরিষেবাটি একটি রিফ্রেশ টোকেন দেয় এবং পূর্ববর্তী (গুলি) অবৈধ করে দেয়, তাই যদি আপনার ক্লায়েন্ট সনাক্ত করে যে ব্যবহারকারীর পরিচয়টি কোনওভাবে আপস করা হয়েছে, আপনি সেই ব্যবহারকারীকে তার পাসওয়ার্ড পরিবর্তন করতে বলতে পারেন । যদি আপনি এটির জন্য ব্ল্যাকলিস্টটি ব্যবহার করতে না চান তবে আপনি (তবে আমি আপনাকে উত্সাহিত করি না) ক্ষেত্রের iatবিরুদ্ধে দাবিটি user.updated_at( jwt.iat < user.updated_atএটিকে জারি করা) বৈধ করতে (যদি জেডব্লিউটি বৈধ না হয়) করতে পারেন।
  • ব্যবহারকারী ইচ্ছাকৃতভাবে লগ আউট করেছেন।

অবশেষে আপনি সবার মতো টোকেনটিকে বৈধতা দিন।

দ্রষ্টব্য 2: নিজেই টোকেনটি (যা আসলেই দীর্ঘ) এটি ক্যাশের কী হিসাবে ব্যবহার করার পরিবর্তে, আমি jtiদাবিটির জন্য একটি ইউইউডি টোকেন তৈরি এবং ব্যবহার করার পরামর্শ দিচ্ছি । কোনটি ভাল এবং আমি মনে করি (নিশ্চিত না যেহেতু এটি কেবলমাত্র আমার মনে আসে) আপনি এই একই ইউআইডিটি সিএসআরএফ টোকেন হিসাবেও ব্যবহার করতে পারেন, এটির সাথে একটি secure/ non-http-onlyকুকি ফিরিয়ে এবং X-XSRF-TOKENজেএস ব্যবহার করে শিরোনামটি যথাযথভাবে প্রয়োগ করে । আপনি সিএসআরএফ চেকগুলির জন্য আরও একটি টোকেন তৈরির কম্পিউটিং কাজটি এড়িয়ে চলেছেন।


9
আপনার ধারণার অবদান রাখতে কখনও দেরি হয় না। আপনার উত্তর দেওয়ার জন্য ধন্যবাদ.
স্মিভিকিপিডিয়া

2
আপনি যদি সার্ভারে একটি ব্ল্যাকলিস্ট সঞ্চয় করেন যা প্রতিটি অনুরোধের জন্য পরীক্ষা করা প্রয়োজন, তবে কেন সহজ প্লেইন পুরানো সেশনটি ব্যবহার করবেন না?
ফ্রাঙ্কলিন ইউ

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

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

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

7

দুঃখিত এই বিষয়ে কিছুটা দেরি হয়ে গেলেও একই রকম উদ্বেগ ছিল এবং এখন একই বিষয়টিতে কিছু অবদান রাখতে চাই।

1) rdegges একটি দুর্দান্ত পয়েন্ট যোগ করেছেন, যে JWT এর "সুরক্ষা" এর সাথে কোন সম্পর্ক নেই এবং কেবল বৈধতা দেয়, যদি কেউ বকেয়া পেলে লোড করে না থাকে বা (স্বাক্ষর করে); এসএসএল লঙ্ঘন প্রতিরোধে সহায়তা করে।

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

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

আমি এর জন্য পসেশন প্রবন্ধের প্রুফ উল্লেখ করেছি এবং সংক্ষেপে দৃ convinced়প্রত্যয়ী।

আমি কিছু অবদান রাখতে পারলে আনন্দিত হব।

চিয়ার্স (y)


0

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


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