আরইএসটি প্রমাণীকরণের স্কিমগুলির সুরক্ষা

228

পটভূমি:

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

এই এসও প্রশ্নগুলি আমাকে শুরু করার জন্য বিশেষভাবে দরকারী ছিল:

আমি অ্যামাজন এস 3 এর প্রমাণীকরণের একটি সরল সংস্করণ ব্যবহার করার কথা ভাবছি (আমি ওআউথ পছন্দ করি তবে এটি আমার প্রয়োজনের জন্য খুব জটিল)। পুনরায় খেলতে আক্রমণ রোধ করার জন্য, অনুরোধে সার্ভারের সরবরাহ করা এলোমেলোভাবে উত্পন্ন নোট যুক্ত করছি ।

প্রশ্ন পেতে:

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

মনে হচ্ছে আমি স্বাক্ষরিত স্ট্রিংয়ের অনুরোধের বডিটির একটি হ্যাশ অন্তর্ভুক্ত করে এটি থেকে রক্ষা করতে পারি। এটি কি নিরাপদ?

— ডিএফ।
সূত্র

6

আপনার বর্ণিত MITM আক্রমণ রোধ করতে আমাজন এস 3 শিরোনামের স্ট্রিংয়ের অংশ হিসাবে একটি সামগ্রী-MD5 অন্তর্ভুক্ত করতে পারে।

— ল্যাজ

8

এমডি 5 একটি অত্যন্ত দুর্বল হ্যাশ ফাংশন এবং এটির ব্যবহার এখন বহু বছর ধরে নিরুৎসাহিত করা হয়েছে: en.wikedia.org/wiki/MD5 । আজকাল SHA2 ব্যবহার করুন। MD5 একটি শঙ্কার সাথে একটি পরিচয়ের সংকট রয়েছে ip

— হেনরিক

6

স্টার্টকম বিনামূল্যে এসএসএল শংসাপত্র সরবরাহ করে যা প্রধান ব্রাউজারগুলিতে শংসাপত্রের সতর্কতাগুলি ফেলে না

— প্লাটো

5

@ সানকেএন্ডারসন (কৌতুক: আমি এটাকে বোকামি মনে করি যে লোকেরা কীভাবে ৯৯.৯৯৯৯৯% সম্পর্কে কথা বলছে যখন গুপ্তচর সংস্থাগুলি ২০০ 2008 সালে ইতিমধ্যে প্রচুর আক্রমণে স্বয়ংক্রিয়ভাবে আক্রমণ চালিয়েছে ইন্টারনেট - এটি একটি বাস্তব সমস্যা মোকাবেলা করার মতো আজব উপায় - "নাহ, কোনও সমস্যা হবে না; আমার ঠাকুরমা এটি হ্যাক করতে সক্ষম হবেন না"

— হেনরিক

2

@ প্লাটো আমি এই দিনগুলিতে নিখরচায় এসএসএল

— শংসাপত্রের

168

পূর্ববর্তী উত্তরটিতে ডেটা ট্রান্সফার প্রসঙ্গে কেবল এসএসএল উল্লেখ করা হয়েছিল এবং প্রকৃতপক্ষে প্রমাণীকরণকে আবৃত করে নি।

আপনি সত্যিই নিরাপদে REST এপিআই ক্লায়েন্টদের অনুমোদনের বিষয়ে জিজ্ঞাসা করছেন। যতক্ষণ না আপনি TLS এর ক্লায়েন্ট প্রমাণীকরণ ব্যবহার করছেন, SSL এর একা বিশ্রাম API- এর জন্য একটি টেকসই প্রমাণীকরণ প্রক্রিয়া নয়। ক্লায়েন্ট লেখকবিহীন এসএসএল কেবলমাত্র সার্ভারকে প্রমাণীকরণ করে যা বেশিরভাগ REST এপিআই-এর জন্য অপ্রাসঙ্গিক কারণ আপনি সত্যই ক্লায়েন্টকে প্রমাণীকরণ করতে চান ।

আপনি যদি টিএলএস ক্লায়েন্ট প্রমাণীকরণ ব্যবহার না করেন তবে আপনাকে ডাইজেস্ট-ভিত্তিক প্রমাণীকরণ স্কিম (অ্যামাজন ওয়েব সার্ভিসের কাস্টম স্কিমের মতো) বা ওআউথ 1.0a বা এমনকি এইচটিটিপি বেসিক প্রমাণীকরণ (তবে কেবল এসএসএল-এর উপরে) ব্যবহার করতে হবে।

এই স্কিমগুলি প্রমাণীকরণ করে যে অনুরোধটি প্রত্যাশিত কেউ পাঠিয়েছিলেন। টিএলএস (এসএসএল) (ক্লায়েন্ট প্রমাণীকরণ ব্যতীত) নিশ্চিত করে যে তারের মাধ্যমে প্রেরিত ডেটা অপরিবর্তিত রয়েছে। এগুলি পৃথক - তবে পরিপূরক - উদ্বেগ।

আগ্রহীদের জন্য, আমি এইচটিটিপি প্রমাণীকরণ প্রকল্প এবং তারা কীভাবে কাজ করে সে সম্পর্কে একটি SO প্রশ্নে প্রসারিত করেছি ।

— লেস হ্যাজলউড
সূত্র

16

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

— টিম গাউটিয়ার

1

ভাল উত্তর. আমি এই দুর্দান্ত উত্সগুলিও একবার দেখার পরামর্শ দিচ্ছি .. owasp.org/index.php/Web_S Services_Security_Cheat_Sheet এবং owasp.org/index.php/REST_Security_Cheat_Sheet (DRAFT)

— dodgy_coder

2

কেবলমাত্র একটি সামান্য বিষয়, তবে এসএসএল ব্যবহারের মাধ্যমে শ্রুতিমধু প্রতিরোধ এবং মাঝের আক্রমণে থাকা মানুষকে প্রতিরোধ করার অতিরিক্ত সুবিধা রয়েছে।

— dodgy_coder

@ লেস হ্যাজলউড আপনি কী ব্যাখ্যা করতে পারবেন যে এইচটিটিপিএসের উপরে এইচটিটিপি বেসিক প্রমাণীকরণ কীভাবে সার্ভারকে এটির সাথে কথা বলে তা নির্ধারণ করতে সহায়তা করতে পারে?

— বসন্ত

@ লেস হ্যাজলউড এখানে আমি একটি প্রশ্নে জিজ্ঞাসা করেছি; tnx stackoverflow.com/questions/14043397/...

— স্প্রিং

60

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

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

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

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

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

(কেবলমাত্র সংযোগটি এসএসএল-র করার অন্তর্ভুক্তগুলি আপডেট করার জন্য আপডেট করা হয়েছে))

— mahemoff
সূত্র

3

আমি মনে করি আপনি প্রতি বছর 30 ডলারে একটি GoDaddy ssl শংসাপত্র পেতে পারেন। ভেরিজাইন এসএসএল শংসাপত্রগুলির জন্য কতটা যায় তা দেখে আমি হতবাক হয়ে গিয়েছিলাম (আমি যদি সঠিকভাবে মনে করি তবে এক বছরে $ 600 বা কোনও কিছুর জন্য?) তবে GoDaddy বিকল্পটি পুরোপুরি সম্ভাব্য।

— ব্রায়ান আর্মস্ট্রং

19

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

— পল্ড

5

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

— ক্যামেরন ওয়ালশ

4

স্টার্টকমের শংসাপত্রগুলি বিনামূল্যে এবং ব্যাপকভাবে স্বীকৃত। cacert.org একটি স্বল্প বিকল্প স্বল্প স্বীকৃতি সহ

— ডিমা তিস্নেক

17

এটি প্রমাণীকরণ সম্পর্কিত যে প্রশ্নটি সম্বোধন করে না।

— স্যাম স্টেইনসবি

8

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

— wowest
সূত্র

2

স্ব-স্বাক্ষরিত শংসাপত্রগুলি নিখরচায়, তবে আফাইক আপনার এখনও একটি স্ট্যাটিক আইপি দরকার।

— ডিএফ।

8

@ ডিএফের শংসাপত্রের জন্য প্রদত্ত বাণিজ্যিক লাইসেন্সের নির্দিষ্ট লাইসেন্স প্রয়োজনীয়তা ব্যতীত স্ট্যাটিক আইপি থাকার কোনও প্রয়োজন নেই।

— ক্রিস মেরিসিক

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

— aled

5

আপনার যদি URL এর পরামিতিগুলির মধ্যে একটির হিসাবে শরীরে হ্যাশ দরকার হয় এবং সেই URL টি একটি ব্যক্তিগত কী দ্বারা স্বাক্ষরিত হয়, তবে মধ্যবর্তী আক্রমণে কেবল শরীরটি প্রতিস্থাপন করতে সক্ষম হবে যা এমন সামগ্রী তৈরি করে যা একই হ্যাশ এমডি 5 হ্যাশ মানগুলি এখনই কমপক্ষে করা সহজ এবং যখন SHA-1 নষ্ট হয়ে যায়, ভাল, আপনি ছবিটি পাবেন।

দেহকে টেম্পারিং থেকে সুরক্ষিত করার জন্য আপনার শরীরের একটি স্বাক্ষর প্রয়োজন, যা একটি মধ্যবর্তী আক্রমণে ভেঙে যাওয়ার সম্ভাবনা কম থাকবে কারণ তারা স্বাক্ষর তৈরি করে এমন ব্যক্তিগত কীটি জানেন না ।

— ZaDDaZ
সূত্র

9

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

— টিম গৌটিয়ার

3

বস্তুত, মূল এস 3 প্রমাণীকরণ নেই বিষয়বস্তুর জন্য অনুমতি দেবেন, সাইন ইন করা একটি দুর্বল MD5 স্বাক্ষর সহ যদ্যপি। আপনি কেবল এইচএমএসিতে একটি কন্টেন্ট-এমডি 5 শিরোনাম (স্বাক্ষর করার জন্য স্ট্রিং) অন্তর্ভুক্ত করার তাদের optionচ্ছিক অনুশীলনটি প্রয়োগ করতে পারেন।

http://s3.amazonaws.com/doc/s3-developer-guide/RESTAuthentication.html

তাদের নতুন ভি 4 প্রমাণীকরণ প্রকল্পটি আরও সুরক্ষিত।

http://docs.aws.amazon.com/general/latest/gr/signature-version-4.html

— djsadinoff
সূত্র

1

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

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

এক্সএমএল এনক্রিপশন (ডাব্লু 3 সি স্ট্যান্ডার্ড)

এক্সএমএল সুরক্ষা

— LiorH
সূত্র