এইচটিটিপিএস-এর মাধ্যমে প্রমাণীকরণ কি আমার অ্যাপ্লিকেশনকে ধীর করবে?


11

আমি একটি ওয়েব অ্যাপ্লিকেশন এবং রেস্টস্টুল ওয়েব পরিষেবা তৈরি করছি।

আমি ওয়েব পরিষেবাতে অনুরোধগুলি প্রমাণ করার সর্বোত্তম উপায় সম্পর্কে বিভিন্ন নিবন্ধ পড়ছি।

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

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


একটি চিন্তাভাবনা, https- র মধ্যে ডেটা লোড করা যায় ac এটি কীভাবে / কীভাবে প্রভাব ফেলবে আমি 100% নিশ্চিত নই।

আমি নিশ্চিত না আমি অনুসরণ করি। আপনি কি বলছেন ক্যাচিং সম্ভব নয়?
Gaz_Edge

সেখানে SSL / HTTPS এবং ওয়েবসার্ভার যে অংশের সাথে অনিচ্ছাকৃত হতে পারে মধ্যে পারস্পরিক ক্রিয়ার রয়েছে - cxf.547215.n5.nabble.com/... - আমি একটি নিরাপদ পরিবেশে বিশ্রাম স্থানে অতিদূরে delved নি তাই এই একটি হয়েছে না আমার জন্য ইস্যু। এপাশে অ্যাডমিন হিসাবে আমার দিনগুলি থেকে চিন্তাভাবনা এবং ইঙ্গিতগুলি থেকে এটি আরও বেশি।

ধন্যবাদ। আপনি বলেছেন যে আপনি নিরাপদ পরিবেশে আরএসটি ব্যবহার করেন নি। এর অর্থ কি আপনি প্রমাণীকরণ ব্যবহার করছেন না? বা আপনি এটি HTTP বেসিককে অন্যভাবে করছেন।
গাজ_এডজ

এটি হয় কোনও প্রমাণীকরণ, বেসিক, বা আইপি ভিত্তিক ... এবং নিখুঁতভাবে একটি ইন্ট্রানেটে (বাহ্যিকভাবে মুখোমুখি কিছুই নয়)।

উত্তর:


11

সবার আগে, SSL (HTTPS) এবং HTTP প্রমাণীকরণ কীভাবে কাজ করে তা বোঝার চেষ্টা করুন।

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

এসএসএল একটি সহজাত নিরাপত্তাহীন চ্যানেলের উপর একটি সুরক্ষিত যোগাযোগ চ্যানেল প্রয়োগ করে। এটি নিম্নলিখিত হিসাবে মোটামুটিভাবে কাজ করে:

  1. সার্ভার একটি স্বাক্ষরিত শংসাপত্র প্রেরণ করে
  2. ক্লায়েন্ট পরিচিত-ভাল স্বাক্ষরকারী কীগুলির তালিকার বিপরীতে শংসাপত্রকে বৈধতা দেয়; শংসাপত্রের স্বাক্ষরগুলি শৃঙ্খলাবদ্ধ হতে পারে, যাতে প্রতিটি নোড বলে যে "যদি আমাকে স্বাক্ষরকারী স্বাক্ষরটি ভাল হয় তবে আমিও আছি", তবে শেষ পর্যন্ত এই চেইনটির ক্লায়েন্টের উপর পূর্বনির্ধারিত মুষ্টিমেয় কয়েকটি বিশ্বস্ত কর্তৃপক্ষের মধ্যে একটির সমাধান করা দরকার।
  3. ক্লায়েন্ট একটি ভাগ করা গোপন পাঠাতে সার্ভারের সর্বজনীন এনক্রিপশন কী ব্যবহার করে key
  4. সার্ভারের ব্যক্তিগত কী ব্যবহার করে ভাগ করা গোপনীয়তা ডিক্রিপ্ট হয় (কারণ কেবল বৈধ সার্ভারের ব্যক্তিগত কী রয়েছে, অন্য সার্ভারগুলি ভাগ করা গোপনটি ডিক্রিপ্ট করতে অক্ষম হবে)
  5. ক্লায়েন্ট প্রকৃত অনুরোধ ডেটা প্রেরণ করে, ভাগ করা গোপন ব্যবহার করে এনক্রিপ্ট করা
  6. সার্ভার অনুরোধ ডেটা ডিক্রিপ্ট করে, তারপরে একটি এনক্রিপ্ট হওয়া প্রতিক্রিয়া প্রেরণ করে
  7. ক্লায়েন্ট প্রতিক্রিয়া ডিক্রিপ্ট করে এবং এটি ব্যবহারকারীর কাছে উপস্থাপন করে।

কয়েকটি গুরুত্বপূর্ণ বিষয় এখানে নোট করুন:

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

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

টি এল; ডিআর: হ্যাঁ, SSL এর + + বেসিক প্রমাণীকরণ একটি ভাল ধারণা, হ্যাঁ, আপনি একটি নিরাপদ সার্ভারে (এবং প্রয়োজন বৈধ শংসাপত্র ), হ্যাঁ, এটা কিছু একটু নিচে, মন্থর করে দেবে কিন্তু না, এই অধিকার সম্পর্কে চিন্তা করতে কিছু নয় এখন।


12

এইচটিটিপিএস (এসএসএল) ব্যবহারকারী প্রমাণীকরণ এফওয়াইআই নয়। এটি কেবলমাত্র 2 টি শেষ পয়েন্টের মধ্যে এনক্রিপশন সরবরাহ করে।

তবে হ্যাঁ, এ থেকে ওভারহেডের কিশোর ক্ষুদ্র একটি বিট রয়েছে (যদিও পরিকল্পনা / হার্ডওয়্যারে পরিবর্তনের জন্য যথেষ্ট নয়)। এখানে দেখো :

/programming/548029/how-much-overhead-does-ssl-impose


7
ছোট ওভারহেডের কারণে পর্যাপ্ত সুরক্ষিত না হওয়াতে +1 আরও সুরক্ষিত থাকার থেকে আরও ভাল
আর্লজ

2
এই উত্তরটি খুব বিভ্রান্তিকর। SSL এর হয় , প্রমাণীকরণ এটা শুধু সাধারণত না ব্যবহারকারী প্রমাণীকরণ। এসএসএল প্রমাণীকরণ করে যে আপনি যে সার্ভারের সাথে কথা বলছেন তা হ'ল সত্যই কে এটি বলে। (সিএর কাজটি কেবল ফেসবুক ডটকমকে ফেসবুকের কাছে শংসাপত্র প্রদান করা)) এসএসএল ক্লায়েন্টের শংসাপত্রগুলি দিয়ে ব্যবহারকারী প্রমাণীকরণ করতে পারে।
josh3736

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

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

6

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

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


3

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

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

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


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

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

2

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

এছাড়াও, তিনি নিবন্ধটি উদ্ধৃত করে একটি Gmail কেস স্টাডি সম্পর্কে এই নিবন্ধটি উল্লেখ করেছেন:

এই বছরের জানুয়ারিতে (2010), জি-মেইল ডিফল্টরূপে প্রত্যেকটির জন্য এইচটিটিপিএস ব্যবহার শুরু করে। পূর্বে এটি একটি বিকল্প হিসাবে চালু করা হয়েছিল, তবে এখন আমাদের সমস্ত ব্যবহারকারীরা সর্বদা তাদের ব্রাউজার এবং গুগলের মধ্যে ইমেল সুরক্ষিত করতে এইচটিটিপিএস ব্যবহার করেন। এটি করার জন্য আমাদের কোনও অতিরিক্ত মেশিন এবং কোনও বিশেষ হার্ডওয়্যার স্থাপন করতে হয়নি। আমাদের প্রোডাকশন ফ্রন্টএন্ড মেশিনে এসএসএল / টিএলএস সিপিইউ লোডের 1% কম, সংযোগ প্রতি 10KB মেমরির কম এবং নেটওয়ার্ক ওভারহেডের 2% এরও কম থাকে accounts অনেক লোক বিশ্বাস করে যে এসএসএল অনেকগুলি সিপিইউ সময় নেয় এবং আমরা আশা করি উপরের সংখ্যাগুলি (প্রথমবারের জন্য সর্বজনীন) এটিকে দূর করতে সহায়তা করবে।

তিনি ব্রাউজার দ্বারা এইচটিটিপিএসের মাধ্যমে ক্লায়েন্ট-সাইড পৃষ্ঠাগুলি ক্যাশে করার ক্ষেত্রে কিছু সাম্প্রতিক উন্নতিরও উল্লেখ করেছেন ।

এ সত্ত্বেও, তিনি উল্লেখ করেছেন, অন্যান্য জরিমানাও রয়েছে, তাদের বেশিরভাগই পারফরম্যান্স নয়, বাস্তবায়নের জন্য ব্যয় করে:

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

আপনার উত্তর প্রসারিত করুন এবং ব্লগ থেকে কিছু হাইলাইট অন্তর্ভুক্ত করুন।
ওয়াল্টার

ব্লগ পোস্ট থেকে হাইলাইট যুক্ত করা হয়।
ড্যানিয়েল ডিনিজ

0

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

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

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


0

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

অন্যরা এখানে যেমন উল্লেখ করেছে, এসএসএল এবং অতিরিক্ত শিরোনাম পাঠানো প্রযুক্তিগতভাবে জিনিসগুলিকে ধীর করে তুলবে তবে এটি কোনওভাবেই তাৎপর্যপূর্ণ হবে না।

আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.