কীভাবে সুরক্ষিতভাবে HTTP- র মাধ্যমে পাসওয়ার্ড প্রেরণ করবেন?

Question

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

সুতরাং প্রশ্নটি হল যে ব্যবহারকারী এবং তার পাসওয়ার্ডটি তৃতীয় পক্ষের বিরুদ্ধে যোগাযোগের ডেটাতে লুকিয়ে থাকতে পারে তার বিরুদ্ধে সুরক্ষিত করার সঠিক উপায়টি কী?

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

সম্পাদনা করুন আমি কিছু গুরুত্বপূর্ণ জিনিস ফেলে রেখেছি।

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

ধন্যবাদ।

Comments

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

— জেরেমি পাওয়েল

আপনি যে সমস্যাটি বর্ণনা করেছেন তা হ'ল এইচটিটিপিএস আবিষ্কার হয়েছিল। পাসওয়ার্ডটি এনক্রিপ্ট করার জন্য আপনি ক্লায়েন্টকে কোনও গোপনীয়তা প্রেরণ করলে কোনও শ্রবণশক্তি এটিকে স্নিগ্ধ করতে এবং রিটার্ন ট্রিপে পাসওয়ার্ডটি ডিক্রিপ্ট করতে সক্ষম হয়।

— jnoss

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

— কর্নেলিজে পেটাক

@ জেরেমি পাওয়েল - আপনি যা বর্ণনা করেছেন তা সাধারণ অনুশীলন হলেও এটি কোনও মধ্যস্থতাকারীর পক্ষেও ঝুঁকিপূর্ণ যারা কুকিকে আবার শিরোনাম করতে এবং কুকিকে পুনরায় ব্যবহার করে ব্যবহারকারীর ছদ্মবেশ তৈরি করতে পারেন। আপনি যদি এইচটিটিপিএস ব্যবহার না করেন তবে মাঝের আক্রমণগুলির মধ্যে থাকা লোকের পক্ষে সুরক্ষা পাওয়া শক্ত

— jnoss

ভবিষ্যতে যে কেউ এই প্রশ্নের কাছে যান: লগ ইন করার পরে আপনাকে সেশন কুকিটিও সুরক্ষিত করতে হবে। (সুতরাং: এইচটিটিপিএস ব্যবহার করা সত্যিই অনেক সহজ))

— আরজান

Answer 1

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

Comments

... এবং "তবে আমাকে একটি এসএসএল শংসাপত্রের জন্য অর্থ প্রদান করতে হবে !!" কোনও বৈধ অভিযোগ নয়, যেহেতু আপনি আজকাল তাদের 30 ডলারে পেতে পারেন। আপনার ডেটা কি 30 টাকা রক্ষার জন্য মূল্যবান নয়?

— ক্যাফে

আপনি যদি সাবস্ক্রাইব করেছেন এমন ওয়েবহোস্ট এসএসএল শংসাপত্র যুক্ত সমর্থন করে না?

— কলমারিয়াস

@ ক্যালমারিয়াস - তারপরে আপনি একটি সত্যিকারের

— ওয়েবহোস্টে

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

— কলমারিয়াস

শেয়ার করা ওয়েবহোস্টগুলি অবশ্যই এন.ইউ.ইউকিপিডিয়া.org

— ব্রায়ান মিন্টন

Answer 2

সুরক্ষিত প্রমাণীকরণ একটি বিস্তৃত বিষয়। সংক্ষেপে, @ জেরেমি-পাওয়েল হিসাবে উল্লেখ করা হয়েছে, সর্বদা এইচটিটিপিএসের পরিবর্তে এইচটিটিপিএস-এর মাধ্যমে শংসাপত্র প্রেরণের পক্ষপাতী। এটি সুরক্ষা সম্পর্কিত প্রচুর মাথাব্যথা দূর করবে।

টিএসএল / এসএসএল শংসাপত্রগুলি আজকাল বেশ সস্তা। আসলে আপনি যদি অর্থ ব্যয় করতে না চান তবে একটি নিখরচায় লেটসেনক্রিপ.অর্গ - স্বয়ংক্রিয় শংসাপত্র কর্তৃপক্ষ রয়েছে।

আপনি আরও একধাপ এগিয়ে যেতে পারেন এবং ক্যাডিসেরওয়ার ডট কম ব্যবহার করতে পারেন যা পটভূমিতে লেটসনক্রিপ্টকে কল করে।

এখন, একবার আমাদের এইচটিটিপিএস চলে গেল ...

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

• ব্যবহারকারীর নাম এবং পাসওয়ার্ড একটি কোলন দ্বারা পৃথক একটি স্ট্রিং মধ্যে মিলিত হয়, যেমন: ব্যবহারকারীর নাম: পাসওয়ার্ড
• ফলাফল স্ট্রিংটি বেস 64 এর আরএফসি2045-MIME বৈকল্পিকটি ব্যবহার করে এনকোড করা হয়েছে, 76 চর / লাইন সীমাবদ্ধ নয়।
• অনুমোদনের পদ্ধতি এবং একটি স্পেস অর্থাৎ "বেসিক" এর পরে এনকোডড স্ট্রিংয়ের আগে রাখা হয়।

উত্স: উইকিপিডিয়া: অনুমোদনের শিরোনাম

এটি কিছুটা জটিল মনে হতে পারে, তবে তা নয়। এখানে প্রচুর ভাল লাইব্রেরি রয়েছে যা আপনার জন্য বাক্সের বাইরে এই কার্যকারিতা সরবরাহ করবে।

আপনার অনুমোদনের শিরোনামটি ব্যবহার করার কয়েকটি ভাল কারণ রয়েছে

1. এটি একটি মান
2. এটি সহজ (আপনি কীভাবে এটি ব্যবহার করবেন তা শিখার পরে)
3. এটি আপনাকে এর মতো ইউআরএল স্তরে লগইন করতে দেয়: https://user:[e-mail]/login(ক্রোম, উদাহরণস্বরূপ এটিকে স্বয়ংক্রিয়ভাবে Authorizationশিরোনামে রূপান্তরিত করবে )

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

Comments

জিইটি প্যারামিটার হিসাবে শংসাপত্রগুলি (পাসওয়ার্ড) প্রেরণে সমস্যা হ'ল ব্যবহারকারী / পাসওয়ার্ডের জুড়িটি সম্ভবত সার্ভার লগগুলিতে শেষ হবে যা কোনও ভাল ধারণা নয়। কোনও পোস্টে শংসাপত্রগুলি পাঠানো ভাল।

— জাফ

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

— ফুলস্ট্যাকফোর্জার

আপনি যা দেখতে পাচ্ছেন না তা লগ করতে পারবেন না। username:password@urlব্রাউজার থেকে অনুবাদ করে: url+ Authorizationঅনুরোধ শিরোনাম। জিইটি কোয়েরিগুলির জন্য ... আমি যেমন বলেছিলাম ঠিক তেমনই, অথোরিজেশন শিরোনাম ব্যবহার করুন। এটা বেশি ভাল.

— ফুলস্ট্যাকফোর্জার

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

— প্রভু 16'16

এটি জোর দেওয়া উচিত যে আপনি যদি ইতিমধ্যে টিএলএস / এসএসএল এর সাথে সংযোগটি এনক্রিপ্ট করে থাকেন তবে এই সমাধানটি কাজ করে। বেস 64 এনক্রিপশন নয়।

— স্কট

Answer 3

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

1. সার্ভার ক্লায়েন্টকে একটি এলোমেলো সংখ্যা, আর পাঠায়।
2. ক্লায়েন্ট এইচ (আর, এস) সার্ভারে ফিরে প্রেরণ করে (যেখানে এইচএইচএ-256 এর মতো এইচ একটি ক্রিপ্টোগ্রাফিক হ্যাশ ফাংশন)
3. সার্ভার এইচ (আর, এস) গণনা করে এবং এটি ক্লায়েন্টের প্রতিক্রিয়ার সাথে তুলনা করে। যদি তারা মেলে, সার্ভারটি ক্লায়েন্টকে পাসওয়ার্ডটি জানে।

সম্পাদনা:

আর এর সতেজতা এবং এইচটিটিপি রাষ্ট্রবিহীন তা নিয়ে এখানে একটি সমস্যা রয়েছে। এটি সার্ভারটি একটি গোপন তৈরি করে এটিকে পরিচালনা করতে পারে, একে Q বলে, যা কেবল সার্ভারই ​​জানে । তারপরে প্রোটোকলটি এরকম হয়:

1. সার্ভারটি এলোমেলো সংখ্যা আর তৈরি করে It
2. ক্লায়েন্ট আর, এইচ (আর, কি) প্রেরণ করে এবং এইচ (আর, এস) গণনা করে এবং সেগুলি আবার সার্ভারে প্রেরণ করে (যেখানে এইচএইচএ-256 এর মতো এইচ একটি ক্রিপ্টোগ্রাফিক হ্যাশ ফাংশন)
3. সার্ভার এইচ (আর, এস) গণনা করে এবং এটি ক্লায়েন্টের প্রতিক্রিয়ার সাথে তুলনা করে। তারপরে এটি আর এবং গণনাগুলি (আবার) এইচ (আর, কি) লাগে। যদি এইচ (আর, কি) এবং এইচ (আর, এস) এর ক্লায়েন্টের সংস্করণটি সার্ভারের পুনরায় গণনার সাথে মিলে যায় তবে সার্ভার ক্লায়েন্টকে সত্যায়িত বলে মনে করে।

লক্ষণীয়, যেহেতু এইচ (আর, কি) ক্লায়েন্ট দ্বারা জাল করা যায় না, এইচ (আর, কি) কুকি হিসাবে কাজ করে (এবং সুতরাং এটি কুকি হিসাবে বাস্তবে প্রয়োগ করা যেতে পারে)।

অন্য সম্পাদনা:

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

Comments

+1 - আপনাকে জাভাস্ক্রিপ্ট (বা ফ্ল্যাশ / সিলভারলাইট / ইত্যাদি) দিয়ে ক্লায়েন্টের পক্ষের প্রতিক্রিয়াটি গণনা করতে হবে

— 42

মানুষকে মাঝখানে বা ছদ্মবেশের আক্রমণগুলিতে থামায় না। যেমন ওয়াইফাইয়ের মাধ্যমে through দেখে মনে হচ্ছে এটি সুরক্ষার একটি ভ্রান্ত ধারণা দেবে, আইএমও।

— টম হাটিন -

এটি নিষ্ক্রিয় আক্রমণ থেকে রক্ষা করে তবে মধ্যের একজন মানুষ এখনও আক্রমণ করতে পারে।

— ডগলাস লিডার

এটির জন্য মূল পাসওয়ার্ডটি জানা সার্ভারের প্রয়োজন।

— ডগলাস লিডার

ক্রিপ্টো পুনরায় উদ্ভাবন করবেন না! (উত্পাদনে)

— ব্রায়ান্ফ

Answer 4

যদি আপনার ওয়েবহোস্ট এটির অনুমতি দেয় বা আপনার সংবেদনশীল ডেটা নিয়ে কাজ করতে হবে, তবে এইচটিটিপিএস, পিরিয়ড ব্যবহার করুন। (এটি প্রায়শই আইন দ্বারা আবাইক প্রয়োজন)।

অন্যথায় আপনি যদি HTTP- র মাধ্যমে কিছু করতে চান। আমি এই জাতীয় কিছু করব।

1. সার্ভারটি এর সর্বজনীন কী লগইন পৃষ্ঠায় এম্বেড করে।
2. ক্লায়েন্ট লগইন ফর্মটি পপুলেটে এবং ক্লিকগুলি জমা দেয়।
3. একটি এজেএক্স অনুরোধ সার্ভার থেকে বর্তমান টাইমস্ট্যাম্প পেয়েছে।
4. ক্লায়েন্ট সাইড স্ক্রিপ্ট শংসাপত্রগুলি, টাইমস্ট্যাম্প এবং একটি লবণ (এনালগের ডেটা যেমন হ'ল মাউস মুভমেন্ট, কী প্রেস ইভেন্টগুলি) থেকে পাবলিক কী ব্যবহার করে এটি এনক্রিপ্ট করে conc
5. ফলাফল হ্যাশ জমা দেয়।
6. সার্ভার হ্যাশ ডিক্রিপ্ট করে
7. টাইমস্ট্যাম্পটি সাম্প্রতিক পর্যায়ে রয়েছে কিনা তা পরীক্ষা করে (কেবলমাত্র 5-10 সেকেন্ডের উইন্ডোকেই সংক্ষিপ্ত করে)। টাইমস্ট্যাম্পটি খুব পুরানো হলে লগইনটিকে প্রত্যাখ্যান করে।
8. হ্যাশটি 20 সেকেন্ডের জন্য সঞ্চয় করে। এই ব্যবধানের সময় লগইন করার জন্য একই হ্যাশ প্রত্যাখ্যান করে।
9. ব্যবহারকারীকে প্রমাণীকরণ করে।

সুতরাং এইভাবে পাসওয়ার্ডটি সুরক্ষিত এবং একই প্রমাণীকরণের হ্যাশটি পুনরায় খেলানো যায় না।

সেশন টোকেনের সুরক্ষা সম্পর্কে। এটি কিছুটা শক্ত। তবে চুরি হওয়া সেশন টোকেনটিকে আরও শক্ত করে পুনরায় ব্যবহার করা সম্ভব।

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

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

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

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

Comments

এই ক্ষেত্রে পাসওয়ার্ডটি আসলেই সুরক্ষিত আছে? কেউ কী পাঠানো হয়েছে তা স্নিগ্ধ করতে পারে না এবং পাবলিক কী ব্যবহার করে এটিকে ডিক্রিপ্ট করতে পারে এবং পরে তারা যখন পরে তা ব্যবহার করে তখন টাইমস্ট্যাম্পটি আপডেট করে? আমি কিছু অনুপস্থিত করছি?

— michaellindahl

@michaellindahl অসমমিতিক এনক্রিপশন মানে কেবলমাত্র ব্যক্তিগত কী - যা সার্ভারটি কখনই ছাড়বে না - জিনিসগুলি ডিক্রিপ্ট করার জন্য ব্যবহৃত হতে পারে। পাবলিক কীগুলি কেবল এনক্রিপ্ট করতে ব্যবহৃত হতে পারে।

— ড্যান প্যান্ট্রি

ব্রাউজার এবং সার্ভারের মধ্যে একটি কম্পিউটার লগইন পৃষ্ঠায় পাবলিক কী পরিবর্তন করতে পারে।

— অ্যান্টি

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

— ভিক্টর

Answer 5

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

Answer 6

আপনি কোনও সুরক্ষিত চ্যানেলের মাধ্যমে সুরক্ষিত পাসওয়ার্ড ব্যবহার করতে এসআরপি ব্যবহার করতে পারেন । সুবিধাটি হ'ল এমনকি যদি কোনও আক্রমণকারী ট্রাফিক স্নিগ্ধ করে, বা সার্ভারের সাথে আপস করে তবে তারা অন্য সার্ভারে পাসওয়ার্ডগুলি ব্যবহার করতে পারে না। https://github.com/alax/jsrp একটি জাভাস্ক্রিপ্ট লাইব্রেরি যা ব্রাউজারে HTTP- র মাধ্যমে সুরক্ষিত পাসওয়ার্ড, বা সার্ভার সাইড (নোডের মাধ্যমে) সমর্থন করে।

Answer 7

এইচটিটিপিএস এত শক্তিশালী কারণ এটি অসমমিতিক ক্রিপ্টোগ্রাফি ব্যবহার করে। এই জাতীয় ক্রিপ্টোগ্রাফি কেবল আপনাকে একটি এনক্রিপ্ট করা টানেল তৈরি করতে দেয় না তবে আপনি যাচাই করতে পারেন যে আপনি সঠিক ব্যক্তির সাথে কথা বলছেন, এবং হ্যাকার নয়।

এখানে জাভা সোর্স কোড যা অসম্পূর্ণ সাইফার আরএসএ (পিজিপি দ্বারা ব্যবহৃত) ব্যবহার করে যোগাযোগ করতে: http://www.hushmail.com/services/downloads/

Answer 8

আপনি আপনার হোস্টের জন্য এসএসএল ব্যবহার করতে পারেন লেটসেনক্রিপ্ট https://letsencrypt.org/ এর মতো এসএসএলের জন্য নিখরচায় প্রকল্প রয়েছে

Comments

প্রশ্নে তৃতীয় বাক্য পরীক্ষা করুন। (এছাড়াও, আপনি কম-বিস্তৃত

— নকলটি

Answer 9

Https ব্যবহার করা এখানে সর্বোত্তম বিকল্প শোনায় (শংসাপত্রগুলি আজকাল এতটা ব্যয়বহুল নয়)। তবে যদি HTTP এর প্রয়োজন হয় তবে আপনি কিছু এনক্রিপশন ব্যবহার করতে পারেন - এটি সার্ভারের পাশে এনক্রিপ্ট করুন এবং ব্যবহারকারীদের ব্রাউজারে ডিক্রিপ্ট করুন (কী আলাদাভাবে প্রেরণ করুন)।

আমরা এটি ব্যবহার করেছি Safevia.net প্রয়োগ করার সময় - ক্লায়েন্টদের (প্রেরক / গ্রহণকারী) পক্ষের মধ্যে এনক্রিপশন করা হয়, যাতে ব্যবহারকারীরা ডেটা নেটওয়ার্ক বা সার্ভার স্তরটিতে উপলব্ধ না করে।