আমি লক্ষ্য করেছি যে বেশিরভাগ সাইট সার্ভারে এইচটিটিপিএসের মাধ্যমে প্লেইনগুলি সরল পাঠ্য হিসাবে প্রেরণ করে। এর পরিবর্তে যদি আমি পাসওয়ার্ডের হ্যাশটি সার্ভারে প্রেরণ করি তবে কি কোনও সুবিধা আছে? এটি আরও সুরক্ষিত হবে?
আমি লক্ষ্য করেছি যে বেশিরভাগ সাইট সার্ভারে এইচটিটিপিএসের মাধ্যমে প্লেইনগুলি সরল পাঠ্য হিসাবে প্রেরণ করে। এর পরিবর্তে যদি আমি পাসওয়ার্ডের হ্যাশটি সার্ভারে প্রেরণ করি তবে কি কোনও সুবিধা আছে? এটি আরও সুরক্ষিত হবে?
উত্তর:
এটি একটি পুরানো প্রশ্ন, তবে আমি এই গুরুত্বপূর্ণ বিষয়ে আমার মতামত দেওয়ার প্রয়োজন অনুভব করেছি। এখানে অনেক ভুল তথ্য রয়েছে
ওপি কখনই এইচটিটিপি-র মাধ্যমে পাসওয়ার্ড প্রেরণের কথা উল্লেখ করেনি - কেবল এইচটিটিপিএস, তবে অনেকে মনে করেন যে কোনও কারণে এইচটিটিপি-র মাধ্যমে পাসওয়ার্ড প্রেরণের প্রশ্নে সাড়া দেওয়া হচ্ছে। বলেছিল:
আমি বিশ্বাস করি যে সরল পাঠ্যে পাসওয়ার্ডগুলি কখনও ধরে রাখা উচিত নয় (একা যাক let এর অর্থ ডিস্কে রাখা হয়নি, এমনকি স্মৃতিতেও নেই।
এখানে প্রতিক্রিয়াযুক্ত লোকেরা মনে হয় এইচটিটিপিএস একটি রূপোর বুলেট, যা এটি নয়। এটি অবশ্যই যথেষ্ট পরিমাণে সহায়তা করে, এবং কোনও প্রমাণীকৃত সেশনে ব্যবহার করা উচিত।
আসল পাসওয়ার্ড কী তা জানার দরকার নেই। যা যা প্রয়োজন তা হ'ল ব্যবহারকারী দ্বারা নির্বাচিত মূল পাঠ্যের উপর ভিত্তি করে একটি প্রমাণীকরণ "কী" উত্পন্ন করার (এবং নির্ভরযোগ্যভাবে পুনরায় উত্পন্ন) একটি নির্ভরযোগ্য উপায়। একটি আদর্শ বিশ্বে এই পাঠ্যটি অবিলম্বে অপরিবর্তনীয় লবণ ব্যবহার করে একটি "কী" তৈরি করা উচিত। এই নুনটি ব্যবহারকারীর শংসাপত্রের জন্য স্বতন্ত্র হওয়া উচিত। আপনার সিস্টেমগুলি পাসওয়ার্ড হিসাবে যা ব্যবহার করে তা এই "কী" হবে। এই পদ্ধতিতে যদি ভবিষ্যতে আপনার সিস্টেমগুলির মধ্যে কখনও আপস হয়ে যায় তবে এই শংসাপত্রগুলি কেবল আপনার নিজের প্রতিষ্ঠানের বিরুদ্ধে কার্যকর হবে এবং ব্যবহারকারীর অলস এবং একই পাসওয়ার্ডটি অন্য কোথাও ব্যবহার করা হয়নি।
সুতরাং আমাদের একটি চাবি আছে। এখন আমাদের ক্লায়েন্ট ডিভাইসে পাসওয়ার্ডের কোনও ট্রেস পরিষ্কার করতে হবে।
এর পরে আপনার সিস্টেমে কীটি পাওয়া দরকার। আপনি কখনই "ক্লিয়ারে" কী বা পাসওয়ার্ড প্রেরণ করবেন না। এমনকি এইচটিটিপিএসেরও বেশি নয়। এইচটিটিপিএস দুর্ভেদ্য নয়। প্রকৃতপক্ষে, অনেক সংস্থাগুলি একটি আস্থাভাজন এমআইটিএম হয়ে উঠতে পারে - আক্রমণ আক্রমণ থেকে নয়, নিজের সুরক্ষা নীতিমালা বাস্তবায়নের জন্য ট্র্যাফিকের উপর পরিদর্শন করার জন্য। এটি এইচটিটিপিএসকে দুর্বল করে, এবং এটি ঘটে কেবল একমাত্র উপায় নয় (যেমন উদাহরণস্বরূপ HTTP MITM আক্রমণে পুনঃনির্দেশ)। কখনই ধরে নিবেন না এটি সুরক্ষিত।
এটি পেতে, আমরা একবারে বন্ধ নাক দিয়ে কীটি হ্যাশ করি। আপনার সিস্টেমে একটি কী জমা দেওয়ার জন্য এই ননসটি অনন্য - এমনকি একই সেশনের সময় একই শংসাপত্রের জন্যও যদি আপনাকে একাধিকবার প্রেরণের প্রয়োজন হয়। প্রমাণীকরণ কীটি পুনরুদ্ধার করার জন্য আপনার নিজের সিস্টেমে এলে আপনি এই ননটিকে বিপরীত করতে পারেন এবং অনুরোধটি প্রমাণীকরণ করতে পারেন।
এটি স্থায়ীভাবে আপনার নিজের সিস্টেমে সংরক্ষণ করার আগে এই সময়ে আমি অপরিবর্তনীয়ভাবে শেষ বারের মতো এটি হ্যাশ করব। আপনার নিজের প্রতিষ্ঠানের প্রমাণ করতে সক্ষম হওয়াতে এসএসও এবং এই জাতীয় উদ্দেশ্যে, শংসাপত্রের নুন অংশীদার সংস্থাগুলির সাথে শংসাপত্রের লবণ ভাগ করে নিতে পারেন can এই পদ্ধতির সর্বোত্তম অংশ হ'ল আপনি কখনই তাদের অনুমোদন ছাড়াই ব্যবহারকারীর দ্বারা উত্পাদিত কিছু ভাগ করে নিচ্ছেন না।
আরও বিস্তৃত গবেষণা করুন, যেমনটি আমি প্রকাশ করেছি তার থেকেও অনেক বেশি রয়েছে, তবে আপনি যদি আপনার ব্যবহারকারীদের সত্যিকারের সুরক্ষা দিতে চান তবে আমার মনে হয় এই পদ্ধতিটি এখানে এখানে সবচেয়ে সম্পূর্ণ প্রতিক্রিয়া।
টি এল; ডিআর:
এইচটিটিপিএস ব্যবহার করুন। নিরাপদে হ্যাশ পাসওয়ার্ডগুলি, অপরিবর্তনীয়ভাবে, প্রতি পাসওয়ার্ডের জন্য একটি অনন্য লবণের সাথে। ক্লায়েন্টে এটি করুন - তাদের আসল পাসওয়ার্ডটি প্রেরণ করবেন না। ব্যবহারকারীদের মূল পাসওয়ার্ড আপনার সার্ভারে প্রেরণ করা কখনই "ওকে" বা "ফাইন" হয় না। মূল পাসওয়ার্ডের কোনও ট্রেস পরিষ্কার করুন। HTTP / HTTPS নির্বিশেষে একটি অদ্ভুত ব্যবহার করুন non এটি অনেক স্তরে অনেক বেশি সুরক্ষিত। (ওপিকে উত্তর)।
যেহেতু এটি এইচটিটিপিএসের ওপরে রয়েছে, হ্যাশিং ছাড়াই পাসওয়ার্ডটি প্রেরণ করা ঠিক ভাল (এইচটিটিপিএস-এর মাধ্যমে এটি প্লেটেক্সট নয়)। তদুপরি, যদি আপনার অ্যাপ্লিকেশনটি বিষয়বস্তু সুরক্ষিত রাখতে এইচটিটিপিএসের উপর নির্ভর করে, তবে এইচটিটিপিএসের মাধ্যমে প্রেরণ করার আগে পাসওয়ার্ডটি হ্যাশ করা অযথা (যেমন কোনও আক্রমণকারী যদি তারের ডেটাটি এনক্রিপ্ট করতে পারে তবে আপনি যেভাবেই ছাঁটাচ্ছেন)
না, আসলে এটি একটি দুর্বলতা হবে। যদি আক্রমণকারী ডাটাবেস থেকে হ্যাশ পেতে সক্ষম হয়, তবে সে এটি ক্র্যাক করার প্রয়োজন ছাড়াই প্রমাণীকরণ করতে এটি ব্যবহার করতে পারে। কোনও পরিস্থিতিতে কোনও ব্যবহারকারী বা আক্রমণকারী হ্যাশ পাসওয়ার্ড নিতে সক্ষম হবেন না।
হ্যাশিং পাসওয়ার্ডগুলির পুরো পয়েন্টটি হ'ল সুরক্ষার অতিরিক্ত স্তর যুক্ত করা। যদি কোনও আক্রমণকারী এসকিউএল ইনজেকশন বা কোনও সুরক্ষিত ব্যাকআপ ব্যবহার করে ডাটাবেস থেকে হ্যাশ এবং লবণ পেতে সক্ষম হয় তবে তাকে জোর করে জোর করে প্লেইন পাঠ্যটি খুঁজে পেতে হবে। জন দ্য রিপারটি সাধারণত সল্ট পাসওয়ার্ড হ্যাশ ভাঙতে ব্যবহৃত হয়।
Https ব্যবহার না করা OWASP শীর্ষ লঙ্ঘন: এ 9-অপর্যাপ্ত পরিবহন স্তর সুরক্ষা
সম্পাদনা:
আপনার প্রয়োগে যদি আপনি একটি হিসাব করেন sha256(client_salt+plain_text_password)
এবং তারপরে সার্ভারের পাশের অন্য হ্যাশ গণনা করেন sha256(server_salt+client_hash)
তবে এটি কোনও গুরুতর দুর্বলতা নয়। যাইহোক, এটি অনুরোধটি শোনার এবং পুনরায় খেলতে সংবেদনশীল। সুতরাং এটি এখনও ডাব্লুএএসপি এ 9 এর স্পষ্ট লঙ্ঘন। তবে এটি এখনও একটি বার্তা ডাইজেস্টকে সুরক্ষা স্তর হিসাবে ব্যবহার করছে।
সর্বনিকটবর্তী বস্তু আমি http- র জন্য একটি ক্লায়েন্ট-সাইড প্রতিস্থাপন দেখেছি একটি হল জাভাস্ক্রিপ্ট কী বিনিময়ে ডাইফি-হেলম্যান । তবে এটি সক্রিয় এমআইটিএম আক্রমণগুলি রোধ করে না এবং এটি প্রযুক্তিগত অবধি OWASP A9 লঙ্ঘন করে। কোডটির লেখকগণ সম্মত হন যে এটি এইচটিটিপিএসের জন্য সম্পূর্ণ প্রতিস্থাপন নয়, তবে এটি ক্লায়েন্ট-সাইড হ্যাশিং সিস্টেমের চেয়ে কোনও কিছুর চেয়ে ভাল এবং ভাল।
তারের উপরে একটি হ্যাশ পাঠানো হ্যাশের উদ্দেশ্যকে পুরোপুরি পরাভূত করে, কারণ কোনও আক্রমণকারী কেবল হ্যাশটি প্রেরণ করতে পারে এবং পাসওয়ার্ডটি ভুলে যেতে পারে। সংক্ষেপে, একটি সিস্টেম যা স্পষ্ট পাঠ্যে একটি হ্যাশ ব্যবহার করে নাস্তিক করে দেয় তা বিস্তৃত খোলা এবং নেটওয়ার্ক স্ন্যিফিং ছাড়া আর কিছুই করার জন্য আপস করা যায় না।
প্লেইন টেক্সটে থাকা পাসওয়ার্ড কখনই (এইচটিটিপিএস ব্যবহার করার সময় নয়) প্রদর্শন করে client এটি ক্লায়েন্ট ছাড়ার আগে অপরিবর্তনীয়ভাবে হ্যাশ করা উচিত কারণ প্রকৃত পাসওয়ার্ড জানার জন্য সার্ভারের কোনও প্রয়োজন নেই।
এরপরে হ্যাশিং অলস ব্যবহারকারীদের সুরক্ষার সমস্যাগুলি সমাধান করে যা একাধিক স্থানে একই পাসওয়ার্ড ব্যবহার করে (আমি জানি আমি কী করি)। তবে এটি হ্যাকার হিসাবে আপনার অ্যাপ্লিকেশনটিকে সুরক্ষা দেয় না যা ডেটাবেস অ্যাক্সেস পেয়েছিল (বা অন্য কোনও উপায়ে হ্যাশটিতে তার হাত পেতে সক্ষম হয়েছিল) কারণ হ্যাকার কেবল হ্যাশ প্রেরণ করতে পারে এবং সার্ভারটিকে এটি গ্রহণ করতে পারে।
এই সমস্যাটি সমাধান করার জন্য আপনি অবশ্যই সার্ভারের প্রাপ্ত হ্যাশটিকে হ্যাশ করতে পারেন এবং একটি দিন কল করতে পারেন।
আমি যে সকেট ভিত্তিক ওয়েব অ্যাপ্লিকেশন তৈরি করছি তাতে ইস্যুটির বিষয়ে আমার দৃষ্টিভঙ্গি হ'ল ক্লায়েন্টের সাথে সংযোগের জন্য সার্ভার একটি লবণ তৈরি করে (হ্যাশিংয়ের আগে এলোমেলো স্ট্রিং যুক্ত করে) এবং এটি সকেট ভেরিয়েবলে সঞ্চয় করে, তারপরে এটি এই হ্যাশ সংক্রমণ করে its ক্লায়েন্টের কাছে ক্লায়েন্ট ব্যবহারকারীদের পাসওয়ার্ড নেয়, তাড়াতাড়ি করে, সার্ভার থেকে লবণ যোগ করে এবং সার্ভারে সঞ্চারিত করার আগে পুরো জিনিসটি হ্যাশ করে। তারপরে এটি সার্ভারে প্রেরণ করা হয়েছে যা এই হ্যাশটিকে হ্যাশের সাথে তুলনা করে (ডিবি + লবণের হ্যাশ)। যতদূর আমি জানি এটি একটি ভাল পদ্ধতির, তবে ন্যায্য বলতে আমি এই বিষয়ে খুব বেশি পড়িনি এবং আমি যদি কোনও বিষয়ে ভুল হয়ে থাকি তবে আমি সংশোধন করতে চাই :)
এইচটিটিপি ডাইজেস্ট ব্যবহার করুন - এটি এমনকি পাসওয়ার্ডটি HTTP- র মধ্যেও সুরক্ষিত করে (তবে সর্বোত্তম ব্যবহারটি https- র মাধ্যমে http ডাইজেস্ট হবে)
উইকিপিডিয়া:
ওয়েব সার্ভার একটি ওয়েব ব্যবহারকারীর (এইচটিটিপি প্রোটোকল ব্যবহার করে) শংসাপত্রগুলির জন্য দর কষাকষির জন্য HTTP ডাইজেস্ট অ্যাক্সেস প্রমাণীকরণ একটি সম্মত পদ্ধতি agreed ডাইজেস্ট প্রমাণীকরণটি বেসিক অ্যাক্সেস প্রমাণীকরণের এনক্রিপ্ট করা ব্যবহারকে বাতিল করার উদ্দেশ্যে তৈরি করা হয়েছে, যাতে নেটওয়ার্কের মাধ্যমে প্লেইনস্টেটে কোনও পাসওয়ার্ড না পাঠিয়েই ব্যবহারকারী পরিচয়টি সুরক্ষিতভাবে প্রতিষ্ঠিত হতে পারে। ডাইজেস্ট প্রমাণীকরণ হ'ল ক্রিপ্টেনালাইসিস প্রতিরোধের জন্য ননস মানগুলির সাথে MD5 ক্রিপ্টোগ্রাফিক হ্যাশিংয়ের একটি অ্যাপ্লিকেশন।
লিঙ্ক: http://en.wikedia.org/wiki/Digest_access_authentication
যদি আপনি "বাস্তব জীবন" ব্যবহার দেখতে চান, আপনি পিএইচপিএমআইআইডি - এমন একটি পিএইচপি ওপেনিড সরবরাহকারী যা HTTP ডাইজেস্ট প্রমাণীকরণ http://siege.org/phpmyid.php ব্যবহার করে
.. বা আপনি পিএইচপি প্রমাণীকরণের নমুনা থেকে শুরু করতে পারেন http://php.net/manual/en/features.http-auth.php
এইচটিপি ডাইজেস্ট আরএফসি: http://www.faqs.org/rfcs/rfc2617
আমার পরীক্ষাগুলি থেকে সমস্ত আধুনিক ব্রাউজার এটি সমর্থন করে ...
আপনি যদি এইচটিটিপিএস-এর মাধ্যমে একটি স্পষ্ট-পাঠ্য পাসওয়ার্ডটি এইচটিটিপিএসের সাথে হ্যাশ পাসওয়ার্ডের সাথে প্রতিস্থাপন করতে চান তবে আপনি সমস্যার জন্য জিজ্ঞাসা করছেন। এইচটিটিপিএস একটি যোগাযোগ চ্যানেল খোলার সময় একটি এলোমেলো, ভাগ করা লেনদেন কী তৈরি করে। এটি ক্র্যাক করা শক্ত, কারণ আপনি (তুলনামূলকভাবে) স্বল্প-মেয়াদী লেনদেনের জন্য ব্যবহৃত ভাগ করা কীটি চাপিয়ে দেওয়ার জন্য ব্রুটে যথেষ্ট সীমাবদ্ধ। যদিও আপনার হ্যাশটি কেবল শুকনো করা যাবে, অফ-লাইন নেওয়া হবে এবং একটি রংধনু টেবিলের দিকে তাকানো হবে বা দীর্ঘ সময় ধরে জোর করে চাপিয়ে দেওয়া উচিত।
তবে এইচটিটিপিএসের মাধ্যমে প্রেরিত একটি মৌলিক ক্লায়েন্ট-পাশের পাসওয়ার্ড অবফেসেশন (হ্যাশ নয়) এর কিছু মূল্য রয়েছে। যদি আমি ভুল না করে থাকি তবে এই কৌশলটি কিছু ব্যাঙ্ক ব্যবহার করে। এই কৌশলটির উদ্দেশ্যটি পাসওয়ার্ডটি তারের উপর দিয়ে স্নিগ্ধ করা থেকে রক্ষা করা নয়। পরিবর্তে, গুপ্তচরবৃত্তি সরঞ্জাম এবং ব্রাউজার প্লাগইনগুলি যে প্রত্যেকটি এইচটিপিপিএস GET / পোষ্ট অনুরোধটি তারা দেখেছিল তা গ্রাহ্য করতে ব্যবহারযোগ্য হওয়া থেকে পাসওয়ার্ডটি থামাতে হবে। আমি একটি দূষিত ওয়েবসাইট থেকে ক্যাপচার হওয়া একটি লগ ফাইল দেখেছি যা ব্যবহারকারীর সেশনগুলি থেকে 400MB এলোমেলো জিইটি / পোষ্ট লেনদেন ছিল। আপনি কল্পনা করতে পারেন যে কেবলমাত্র এইচটিটিপিএস ব্যবহার করা ওয়েবসাইটগুলি লগের মধ্যে পরিষ্কার-পাঠ্য পাসওয়ার্ড সহ প্রদর্শিত হবে, তবে খুব বেসিক অবলম্বন (আরওটি 13) সহ ওয়েবসাইটগুলি পাসওয়ার্ডগুলির সাথে দেখাবে যা অবিলম্বে ব্যবহারের নয়।
আপনি যদি কোনও https সার্ভারের সাথে সংযুক্ত থাকেন তবে সার্ভার এবং ব্রাউজারের মধ্যে ডেটা স্ট্রিম এনক্রিপ্ট করা উচিত। ডেটা প্রেরণের আগে এবং পুনরুদ্ধারের পরে কেবল প্লেইন পাঠ্য। উইকিপিডিয়া নিবন্ধ
দাবি অস্বীকার: আমি কোনও সুরক্ষার বিশেষজ্ঞকেই বাড়িয়ে তুলছি না - এবং আমি এই আশা নিয়ে পোস্ট করছি যে অন্যরা আমার অবস্থানকে অত্যধিক সতর্ক বা অসম্ভব বলে সমালোচনা করবে এবং আমি এ থেকে শিখব। এই বলেছিলাম, আমি কেবলমাত্র সেই হ্যাশটিকে জোর দিয়ে বলতে চাই যখন এটি আপনার ক্লায়েন্টকে ছেড়ে যায় তার অর্থ এই নয় যে এটি ডাটাবেসে রাখার আগে ব্যাকএন্ডে আপনাকে হ্যাশ করতে হবে না।
দুজনেই কর
উভয়ই করুন কারণ:
রাইড ওভারে হ্যাশিং ট্রান্সপোর্টের দুর্বলতাগুলি কভার করতে সহায়তা করে, যদি এসএসএল সংযোগটি আপত্তি করা থাকে তবে তারা এখনও কাঁচা পাসওয়ার্ড দেখতে পাবে না। অনুমোদিত ব্যবহারকারীদের ছদ্মবেশ তৈরি করতে সক্ষম হওয়ার বিষয়টি বিবেচ্য নয়, তবে এটি আপনার ব্যবহারকারীদের ডাব্লু / তাদের ইমেলের পাসওয়ার্ডগুলি পড়া থেকে সুরক্ষা দেবে will বেশিরভাগ লোকেরা সর্বোত্তম অনুশীলন অনুসরণ করেন না এবং তাদের অ্যাকাউন্টগুলির জন্য একই পাসওয়ার্ড ব্যবহার করেন না, তাই এটি আপনার দর্শকদের জন্য মারাত্মক দুর্বলতা হতে পারে।
যদি কেউ, কোনওভাবে ডাটাবেস থেকে পাসওয়ার্ড পড়তে সক্ষম হয় (এটি ঘটে, এসকিউএল ইঞ্জেকশনটি ভাবেন) তবে তারা এখনও আমার এপিআইয়ের মাধ্যমে ব্যবহারকারীদের ছদ্মবেশযুক্ত সুবিধাপ্রাপ্ত পদক্ষেপগুলি কার্যকর করতে সক্ষম হবে না। এটি হ্যাশ অসম্পূর্ণতার কারণে; এমনকি তারা আপনার ডিবিতে থাকা হ্যাশটি জানলেও, তারা এটি তৈরি করতে ব্যবহৃত মূল কীটি জানতে পারবে না এবং এটিই আপনার লেখক মিডলওয়্যার প্রমাণীকরণের জন্য ব্যবহার করে। এজন্য আপনার হ্যাশ স্টোরেজটি সর্বদা লবণ করা উচিত।
মঞ্জুর, তারা আপনার ডেটাবেস থেকে যা চান তা পড়তে ফ্রি লাগাতে পারলে তারা অন্যান্য অনেক ক্ষতি করতে পারে।
আমি কেবল এখানে জোর দিতে চাই যে আপনি যদি আপনার ক্লায়েন্টদের থেকে বিদায় নেওয়ার আগে কী হ্যাশ করার সিদ্ধান্ত নেন, তবে তা যথেষ্ট নয় - ব্যাকএন্ড হ্যাশিং, ইমো, আরও গুরুত্বপূর্ণ এবং এটি কারণ: যদি কেউ আপনার থেকে ট্র্যাফিককে বাধা দিচ্ছে ক্লায়েন্ট, তারপরে তারা password
ক্ষেত্রের সামগ্রীগুলি দেখতে পাবেন । এটি হ্যাশ, বা সাধারণ পাঠ্য যাই হোক না কেন, কোনও ব্যাপার নয় - তারা কোনও অনুমোদিত ক্লায়েন্টের ছদ্মবেশ তৈরি করতে এটি ভারব্যাটিমটি অনুলিপি করতে পারে। (আপনি যদি ব্যবহারকারীদের অনুসরণ করেন এমন পদক্ষেপগুলি অবলম্বন না করেন তবে ব্যবহারকারীরা 29299591 রুপরেখা বর্ণনা করেন এবং আমি আপনাকে প্রস্তাব দিই)। অন্যদিকে ডিবি কলামটি হ্যাশ করা একটি প্রয়োজনীয়তা এবং এটি কার্যকর করা মোটেই কঠিন নয়।
এসএসএল / টিএলএস কি ননদের প্রতিস্থাপন করছে না? এসএসএল / টিএলএস রিপ্লে আক্রমণগুলির বিরুদ্ধেও সুরক্ষা দেয় বলে আমি এর অতিরিক্ত মূল্য দেখতে পাচ্ছি না।
পাসওয়ার্ডটি হ্যাশ করা এবং একটি এনক্রিপ্ট করা চ্যানেলের মাধ্যমে এটি প্রেরণে এটি আসলে কম সুরক্ষিত হবে। আপনি ক্লায়েন্টের উপর আপনার হ্যাশিং অ্যালগরিদমটি প্রকাশ করবেন। হ্যাকাররা কেবল পাসওয়ার্ডের হ্যাশটি স্নিগ্ধ করতে পারে এবং পরে এটি হ্যাক করতে ব্যবহার করতে পারে।
এইচটিটিপিএস ব্যবহার করে আপনি কোনও হ্যাকারকে একটি একক উত্স থেকে পাসওয়ার্ড পেতে বাধা দেন, যেহেতু এইচটিটিপিএস দুটি এনক্রিপ্টযুক্ত দুটি চ্যানেল ব্যবহার করে।
কোনও সুবিধা আছে কিনা এবং এটি আরও (বা কম) সুরক্ষিত কিনা তা বাস্তবায়নের উপর নির্ভর করে। তর্কসাপেক্ষভাবে কিছু সুবিধা রয়েছে তবে আপনি যদি এটি খারাপভাবে প্রয়োগ করেন তবে আপনি অবশ্যই একটি সমাধান তৈরি করতে পারেন যা একটি সরলখর পাসওয়ার্ড এমনকি পাসওয়ার্ডের চেয়ে কম সুরক্ষিত।
এটি দুটি ধরণের আক্রমণগুলির দৃষ্টিকোণ থেকে দেখা যেতে পারে - একটি নেটওয়ার্ক ট্র্যাফিকের অ্যাক্সেস সহ এবং অন্যটি ডাটাবেস অ্যাক্সেস সহ।
যদি আপনার আক্রমণকারী নেটওয়ার্ক ট্র্যাফিকের প্লেইন টেক্সট সংস্করণটিকে বাধা দিতে পারে, তবে পাসওয়ার্ডের একটি হ্যাশ দেখা প্লেইন্টেক্সটে পাসওয়ার্ড দেখার চেয়ে সুরক্ষিত। যদিও আক্রমণকারীটি এখনও এই হ্যাশটি ব্যবহার করে আপনার সার্ভারে লগ ইন করতে পারে, অন্য সিস্টেমে দরকারী হতে পারে এমন পাসওয়ার্ড নির্ধারণের জন্য সেই হ্যাশের একটি ব্রুট-ফোর্স ক্র্যাক (কখনও কখনও প্রাক-গণনা) প্রয়োজন। লোকদের বিভিন্ন সিস্টেমে বিভিন্ন পাসওয়ার্ড ব্যবহার করা উচিত, তবে প্রায়শই তা হয় না।
যদি কোনও আক্রমণকারী ডাটাবেসে অ্যাক্সেস অর্জন করে, সম্ভবত কোনও ব্যাকআপের অনুলিপি দ্বারা, তবে আপনি নিশ্চিত করতে চাইবেন যে কেবলমাত্র সেই জ্ঞান দিয়ে কেউ লগ ইন করতে পারে না। উদাহরণস্বরূপ, আপনি লগইন নামের হিসাবে সল্ট করা একটি হ্যাশ হিসাবে সংরক্ষণ করেছেন hash(login_name+password)
এবং সরাসরি তুলনার জন্য আপনি ক্লায়েন্টের কাছ থেকে একই হ্যাশটি পাস করেছেন, তবে আক্রমণকারী এলোমেলোভাবে একটি ব্যবহারকারীকে বেছে নিতে পারে, ডাটাবেস থেকে হ্যাশ পাঠাতে পারে এবং লগ ইন করতে পারে এই ব্যবহারকারীর পাসওয়ার্ড না জেনে, লঙ্ঘনের সুযোগ বাড়িয়ে দেওয়া। সেক্ষেত্রে প্লেইন টেক্সটে পাসওয়ার্ডটি প্রেরণ করা আরও সুরক্ষিত হত কারণ আক্রমণকারীকে লগ ইন করার জন্য প্লেইনেক্সটটি জানা দরকার ছিল, এমনকি ডেটাবেসের একটি অনুলিপিও ছিল। বাস্তবায়নের মূল বিষয়টি এখানেই। আপনি যদি সেই পাসওয়ার্ডের একটি সাদামাটা পাসওয়ার্ড বা ক্লায়েন্ট-সাইড হ্যাশ প্রেরণ করেন, আপনার সার্ভার-সাইডে সেই মানটি হ্যাশ করা উচিত এবং ব্যবহারকারীর রেকর্ডে থাকা হ্যাশটির সাথে সেই হ্যাশটির তুলনা করা উচিত।
মাথায় রাখার ধারণাগুলি: