পাসওয়ার্ডটি সার্ভারে প্রেরণের আগে আমার কি হ্যাশ করা উচিত?


110

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


5
@ জ্যাডার ডায়াস: আমি জানি আপনি এটি জিজ্ঞাসা করেননি, তবে আপনি এটি হ্যাশ করলে এটি আর সুরক্ষিত হবে না, তারপরে এটি https- র মাধ্যমে প্রেরণ করবে। বাস্তবে, এটি এটি কম সুরক্ষিত করতে পারে, যেহেতু আপনি আপনার লবণ প্রকাশ করেন। এছাড়াও, (এখানে আমার পিছনের দিকের কথা বলছি), অ্যালগরিদমের মিশ্রণের ফলে আরও বেশি হ্যাশ সংঘর্ষ হতে পারে এবং এটি আরও হ্যাকযোগ্য হয়ে উঠতে পারে।
মের্লিন মরগান-গ্রাহাম

@ মেরলিন "হ্যাশের সংঘর্ষ" ভাল পয়েন্ট!
যাদ্দার ডায়াস

অ্যালগরিদমগুলি মেশানো মোটেও সংঘর্ষের সম্ভাবনা বাড়ায় না। এটি হ্যাশ ফাংশনের পুরো পয়েন্ট। যে কোনও ইনপুট এনট্রপি দেওয়া হয়েছে, রিটার্ন আউটপুট যার সম্ভাব্য আউটপুট স্পেসে যে কোনও জায়গায় থাকার সমান সম্ভাবনা রয়েছে।
জেজে

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

উত্তর:


155

এটি একটি পুরানো প্রশ্ন, তবে আমি এই গুরুত্বপূর্ণ বিষয়ে আমার মতামত দেওয়ার প্রয়োজন অনুভব করেছি। এখানে অনেক ভুল তথ্য রয়েছে

ওপি কখনই এইচটিটিপি-র মাধ্যমে পাসওয়ার্ড প্রেরণের কথা উল্লেখ করেনি - কেবল এইচটিটিপিএস, তবে অনেকে মনে করেন যে কোনও কারণে এইচটিটিপি-র মাধ্যমে পাসওয়ার্ড প্রেরণের প্রশ্নে সাড়া দেওয়া হচ্ছে। বলেছিল:

আমি বিশ্বাস করি যে সরল পাঠ্যে পাসওয়ার্ডগুলি কখনও ধরে রাখা উচিত নয় (একা যাক let এর অর্থ ডিস্কে রাখা হয়নি, এমনকি স্মৃতিতেও নেই।

এখানে প্রতিক্রিয়াযুক্ত লোকেরা মনে হয় এইচটিটিপিএস একটি রূপোর বুলেট, যা এটি নয়। এটি অবশ্যই যথেষ্ট পরিমাণে সহায়তা করে, এবং কোনও প্রমাণীকৃত সেশনে ব্যবহার করা উচিত।

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

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

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

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

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

আরও বিস্তৃত গবেষণা করুন, যেমনটি আমি প্রকাশ করেছি তার থেকেও অনেক বেশি রয়েছে, তবে আপনি যদি আপনার ব্যবহারকারীদের সত্যিকারের সুরক্ষা দিতে চান তবে আমার মনে হয় এই পদ্ধতিটি এখানে এখানে সবচেয়ে সম্পূর্ণ প্রতিক্রিয়া।

টি এল; ডিআর:

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


25
আমি কেবলমাত্র জিমেইল এবং ফেসবুকটি পরীক্ষা করেছি - ক্রোম বিকাশকারী সরঞ্জামগুলি আমার ইউজারনেম এবং পাসওয়ার্ড সম্বলিত সরল (নিরবিচ্ছিন্ন) পাঠ্যে একটি urlncoded বার্তা দিয়ে POST উভয়কেই বলে। কীভাবে / কেন বড় খেলোয়াড়রা ক্লায়েন্টের উপর ননস সল্টিং ব্যবহার করছেন না?
গ্রিমওয়েল

18
আপনি একটি ননসের সাথে কীটি হ্যাশ করেছেন এবং দাবি করেছেন যে সার্ভারের পাশ দিয়ে ননসটিকে বিপরীত করতে সক্ষম হবেন। আপনি কি তখন হ্যাশটিকে আঘাত করছেন? অথবা আপনি যখন একটি হ্যাশ = হ্যাশ (গোপনীয়তা + ননস) পাবেন তখন আপনি কীভাবে কোনও গালাগালি ফিরে পাবেন কীভাবে HASH একটি অপরিবর্তনীয় ফাংশন হওয়া উচিত। আপনি কি এটি বাস্তবায়ন করেছেন? আমি মনে করি না আপনি যা ব্যাখ্যা করেছেন তা বাস্তবসম্মত। আপনি কি প্রোটোকলের একটি ফ্লোচার্ট তৈরি করতে পারেন?
রৌপ্য

19
আপনি যদি এইচটিটিপিএসকে বিশ্বাস না করেন তবে প্রতিটি একক প্রচেষ্টা অর্থহীন! আপনার কোডটি নিজেই তারের মাধ্যমে প্রেরণ করা হয়েছে এবং আক্রমণকারী ট্রানজিটে পাসওয়ার্ড সুরক্ষিত করার জন্য আপনার সমস্ত প্রচেষ্টা সংশোধন / প্রতিস্থাপন করতে পারে
সাজিদ কল্লা

3
একটি এমআইটিএম যা প্রত্যেকে পুনর্লিখন করতে পারে তা ননসকে আবারও লিখতে পারে। বা কি বললেন সাজিদ।
লিউজ

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

24

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


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

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

2
এসএসএলের উদ্দেশ্য (এইচটিটিপিএস = এসএসএল এর মাধ্যমে এইচটিটিপি) এমআইটিএম ব্যর্থ করা।
yfeldblum

1
@ কার্নল্ড - এমআইএনটিএম - HTTP এ পুনঃনির্দেশ সম্পর্কে কী? বেশিরভাগ লোক খেয়াল করবে? sslstrip - securityfocus.com/brief/910
Nate গ

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

17

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

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

Https ব্যবহার না করা OWASP শীর্ষ লঙ্ঘন: এ 9-অপর্যাপ্ত পরিবহন স্তর সুরক্ষা

সম্পাদনা: আপনার প্রয়োগে যদি আপনি একটি হিসাব করেন sha256(client_salt+plain_text_password)এবং তারপরে সার্ভারের পাশের অন্য হ্যাশ গণনা করেন sha256(server_salt+client_hash)তবে এটি কোনও গুরুতর দুর্বলতা নয়। যাইহোক, এটি অনুরোধটি শোনার এবং পুনরায় খেলতে সংবেদনশীল। সুতরাং এটি এখনও ডাব্লুএএসপি এ 9 এর স্পষ্ট লঙ্ঘন। তবে এটি এখনও একটি বার্তা ডাইজেস্টকে সুরক্ষা স্তর হিসাবে ব্যবহার করছে।

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


4
প্রকৃতপক্ষে আমি আবার এটি সার্ভারে হ্যাশ করব, সুতরাং দয়া করে আপনার উত্তরটি এই পরিস্থিতিটি বিবেচনা করে সম্পাদনা করুন।
জাদের দিয়া

@ রুক https এর সাথে একসাথে ডিফাই-হেলমানম্যান কী এক্সচেঞ্জ ব্যবহার করছে একটি "অকেজো" সমাধান? (আমার অর্থ আমরা কেবল https ব্যবহার করতে পারি এবং ডিফি হেলম্যান সুরক্ষা ইমামো বাড়িয়ে দেয় না)
মিশেল

@ মিশেল কোগান একটি ডিএইচ কী এক্সচেঞ্জ অন্যান্য সরঞ্জামের সাথে এইচটিটিপিতে ব্যবহার করা যেতে পারে।
রোক

1
@ রুক সার্ভারে একটি হ্যাশ প্রয়োগ করা একটি সেরা অনুশীলন, তাই আমি মনে করি আপনার ক্লায়েন্ট-সাইড হ্যাশিং বাতিল না করার জন্য আপনার উত্তরের শুরুটি আপডেট করা উচিত এবং কেবল তখনই উল্লেখ করুন যে সার্ভারের সঞ্চিত হ্যাশ এবং লবণের বিষয়টি কখনই প্রকাশ করা উচিত নয়।
লেভেন্তে পঞ্চজেল

8

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


2
এটি সম্পূর্ণ বুলਸ਼ মনে হচ্ছে ... পাসওয়ার্ডের চেয়ে হ্যাশ কম সুরক্ষিত কীভাবে?
লেভেন্তে পঞ্চজিল

1
এটি কেবল "বোবা" হ্যাশগুলির ক্ষেত্রেই সত্য। এটি বিবেচনা করুন: একটি সার্ভার ক্লায়েন্টকে একটি লবণ এস প্রেরণ করে এবং ক্লায়েন্টটি হ্যাশ (এস + পাসওয়ার্ড) করে এবং এটি সার্ভারে প্রেরণ করে। সার্ভার কেবলমাত্র বর্তমান সেশনের জন্য নির্দিষ্ট নির্দিষ্ট হ্যাশকে সম্মান করে। একজন আক্রমণকারী সত্যই হ্যাশটি প্রেরণ করতে এবং পাসওয়ার্ডটি ভুলে যেতে পারে তবে কেবল সেশনের জন্য। সুতরাং এটি সরল-পাঠ্যের চেয়ে বেশি সুরক্ষিত।
হ্যালো ওয়ার্ল্ড

আপডেট: ডাইজেস্ট অ্যাক্সেস প্রমাণীকরণ আরও বেশি পরিশীলিত: en.wikedia.org/wiki/Digest_access_authentication
হ্যালো ওয়ার্ল্ড

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

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

5

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

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

এই সমস্যাটি সমাধান করার জন্য আপনি অবশ্যই সার্ভারের প্রাপ্ত হ্যাশটিকে হ্যাশ করতে পারেন এবং একটি দিন কল করতে পারেন।

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


3

এইচটিটিপি ডাইজেস্ট ব্যবহার করুন - এটি এমনকি পাসওয়ার্ডটি 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

আমার পরীক্ষাগুলি থেকে সমস্ত আধুনিক ব্রাউজার এটি সমর্থন করে ...


এইচটিটিপি ডাইজেস্ট আমার এই প্রশ্নের অর্থ যা বোঝায় তা প্রয়োগ করে, তবে যদি আমরা এইচটিটিপিএস ডাইজেস্ট (এসএসএল + এইচটিটিপি ডাইজেস্ট) ব্যবহার করি তবে আমাদের কোনও সুবিধা হবে?
জ্যাডার ডায়াস

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

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

3

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

তবে এইচটিটিপিএসের মাধ্যমে প্রেরিত একটি মৌলিক ক্লায়েন্ট-পাশের পাসওয়ার্ড অবফেসেশন (হ্যাশ নয়) এর কিছু মূল্য রয়েছে। যদি আমি ভুল না করে থাকি তবে এই কৌশলটি কিছু ব্যাঙ্ক ব্যবহার করে। এই কৌশলটির উদ্দেশ্যটি পাসওয়ার্ডটি তারের উপর দিয়ে স্নিগ্ধ করা থেকে রক্ষা করা নয়। পরিবর্তে, গুপ্তচরবৃত্তি সরঞ্জাম এবং ব্রাউজার প্লাগইনগুলি যে প্রত্যেকটি এইচটিপিপিএস GET / পোষ্ট অনুরোধটি তারা দেখেছিল তা গ্রাহ্য করতে ব্যবহারযোগ্য হওয়া থেকে পাসওয়ার্ডটি থামাতে হবে। আমি একটি দূষিত ওয়েবসাইট থেকে ক্যাপচার হওয়া একটি লগ ফাইল দেখেছি যা ব্যবহারকারীর সেশনগুলি থেকে 400MB এলোমেলো জিইটি / পোষ্ট লেনদেন ছিল। আপনি কল্পনা করতে পারেন যে কেবলমাত্র এইচটিটিপিএস ব্যবহার করা ওয়েবসাইটগুলি লগের মধ্যে পরিষ্কার-পাঠ্য পাসওয়ার্ড সহ প্রদর্শিত হবে, তবে খুব বেসিক অবলম্বন (আরওটি 13) সহ ওয়েবসাইটগুলি পাসওয়ার্ডগুলির সাথে দেখাবে যা অবিলম্বে ব্যবহারের নয়।


"তবে খুব প্রাথমিক অবলম্বন (ROT13) সহ ওয়েবসাইটগুলি সেই সাথে পাসওয়ার্ডগুলি প্রদর্শন করবে যা অবিলম্বে ব্যবহারের নয়" - এটি মূল বিবৃতিটির সাথে বৈপরীত্য প্রদর্শন করে। মূলটি হ'ল এগুলি ব্যবহারের তাড়াতাড়ি নয়, তবে এটি সত্যই নিরর্থক। পাসওয়ার্ড এবং এর ROT13 সমতুল্য। তবে আপনি যদি পাসওয়ার্ডটি SHA2 করেন তবে এটি লগগুলিতে উপস্থিত হবে না (যাতে আপনার প্রশাসকরা অন্যান্য সিস্টেমে ব্যবহারকারীর সম্ভাব্য পাসওয়ার্ডগুলি জানতে পারবেন না) এবং আপনি প্রায় প্রতিটি গোপনীয়তা আইন লঙ্ঘন করেন না।
লেভেন্তে পঞ্চজেল

2

আপনি যদি কোনও https সার্ভারের সাথে সংযুক্ত থাকেন তবে সার্ভার এবং ব্রাউজারের মধ্যে ডেটা স্ট্রিম এনক্রিপ্ট করা উচিত। ডেটা প্রেরণের আগে এবং পুনরুদ্ধারের পরে কেবল প্লেইন পাঠ্য। উইকিপিডিয়া নিবন্ধ


প্রক্সিরা কি এই ডেটাটিকে বাধা দেয় না?
জাদের দিয়া

আমি এটি বুঝতে পারি যে তারা তা করে তবে প্রক্সিটি এনক্রিপশন / ডিক্রিপশন জন্য দায়বদ্ধ নয় এবং যদি না এটি একটি অসাধু প্রক্সি কেবল ডেটা পাস করে। এনক্রিপশন ধরণ এবং শক্তি সার্ভার এবং ক্লায়েন্ট উভয় সমর্থন করতে পারে তার উপর নির্ভর করে।
জ্যাক

1
প্রক্সিটি আপত্তিহীন হলেও, এটি সার্ভারের সর্বজনীন কী ব্যবহার করে এনক্রিপ্ট করা হওয়ায় এটি ডিক্রিপ্ট করতে পারে না। কোনও প্রক্সিটি ডেটা ডিক্রিপ্ট করার একমাত্র উপায় হ'ল সার্ভারের শংসাপত্রকে একটি আলাদা কী দিয়ে
ফাঁকি দেওয়া

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

2

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

দুজনেই কর

উভয়ই করুন কারণ:

  1. রাইড ওভারে হ্যাশিং ট্রান্সপোর্টের দুর্বলতাগুলি কভার করতে সহায়তা করে, যদি এসএসএল সংযোগটি আপত্তি করা থাকে তবে তারা এখনও কাঁচা পাসওয়ার্ড দেখতে পাবে না। অনুমোদিত ব্যবহারকারীদের ছদ্মবেশ তৈরি করতে সক্ষম হওয়ার বিষয়টি বিবেচ্য নয়, তবে এটি আপনার ব্যবহারকারীদের ডাব্লু / তাদের ইমেলের পাসওয়ার্ডগুলি পড়া থেকে সুরক্ষা দেবে will বেশিরভাগ লোকেরা সর্বোত্তম অনুশীলন অনুসরণ করেন না এবং তাদের অ্যাকাউন্টগুলির জন্য একই পাসওয়ার্ড ব্যবহার করেন না, তাই এটি আপনার দর্শকদের জন্য মারাত্মক দুর্বলতা হতে পারে।

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

মঞ্জুর, তারা আপনার ডেটাবেস থেকে যা চান তা পড়তে ফ্রি লাগাতে পারলে তারা অন্যান্য অনেক ক্ষতি করতে পারে।

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


1

এসএসএল / টিএলএস কি ননদের প্রতিস্থাপন করছে না? এসএসএল / টিএলএস রিপ্লে আক্রমণগুলির বিরুদ্ধেও সুরক্ষা দেয় বলে আমি এর অতিরিক্ত মূল্য দেখতে পাচ্ছি না।

সূত্র। https://en.wikipedia.org/wiki/Cryptographic_nonce



0

পাসওয়ার্ডটি হ্যাশ করা এবং একটি এনক্রিপ্ট করা চ্যানেলের মাধ্যমে এটি প্রেরণে এটি আসলে কম সুরক্ষিত হবে। আপনি ক্লায়েন্টের উপর আপনার হ্যাশিং অ্যালগরিদমটি প্রকাশ করবেন। হ্যাকাররা কেবল পাসওয়ার্ডের হ্যাশটি স্নিগ্ধ করতে পারে এবং পরে এটি হ্যাক করতে ব্যবহার করতে পারে।

এইচটিটিপিএস ব্যবহার করে আপনি কোনও হ্যাকারকে একটি একক উত্স থেকে পাসওয়ার্ড পেতে বাধা দেন, যেহেতু এইচটিটিপিএস দুটি এনক্রিপ্টযুক্ত দুটি চ্যানেল ব্যবহার করে।


1
আসলে আমি আবার সার্ভারে এটি হ্যাশ করব এবং আমি যে কোনও উপায়ে এইচটিটিপিএস ব্যবহার করব, সুতরাং দয়া করে আপনার উত্তরটি এই দৃশ্যের সাথে বিবেচনা করে সম্পাদনা করুন।
জাদের দিয়া

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

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

0

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

এটি দুটি ধরণের আক্রমণগুলির দৃষ্টিকোণ থেকে দেখা যেতে পারে - একটি নেটওয়ার্ক ট্র্যাফিকের অ্যাক্সেস সহ এবং অন্যটি ডাটাবেস অ্যাক্সেস সহ।

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

যদি কোনও আক্রমণকারী ডাটাবেসে অ্যাক্সেস অর্জন করে, সম্ভবত কোনও ব্যাকআপের অনুলিপি দ্বারা, তবে আপনি নিশ্চিত করতে চাইবেন যে কেবলমাত্র সেই জ্ঞান দিয়ে কেউ লগ ইন করতে পারে না। উদাহরণস্বরূপ, আপনি লগইন নামের হিসাবে সল্ট করা একটি হ্যাশ হিসাবে সংরক্ষণ করেছেন hash(login_name+password)এবং সরাসরি তুলনার জন্য আপনি ক্লায়েন্টের কাছ থেকে একই হ্যাশটি পাস করেছেন, তবে আক্রমণকারী এলোমেলোভাবে একটি ব্যবহারকারীকে বেছে নিতে পারে, ডাটাবেস থেকে হ্যাশ পাঠাতে পারে এবং লগ ইন করতে পারে এই ব্যবহারকারীর পাসওয়ার্ড না জেনে, লঙ্ঘনের সুযোগ বাড়িয়ে দেওয়া। সেক্ষেত্রে প্লেইন টেক্সটে পাসওয়ার্ডটি প্রেরণ করা আরও সুরক্ষিত হত কারণ আক্রমণকারীকে লগ ইন করার জন্য প্লেইনেক্সটটি জানা দরকার ছিল, এমনকি ডেটাবেসের একটি অনুলিপিও ছিল। বাস্তবায়নের মূল বিষয়টি এখানেই। আপনি যদি সেই পাসওয়ার্ডের একটি সাদামাটা পাসওয়ার্ড বা ক্লায়েন্ট-সাইড হ্যাশ প্রেরণ করেন, আপনার সার্ভার-সাইডে সেই মানটি হ্যাশ করা উচিত এবং ব্যবহারকারীর রেকর্ডে থাকা হ্যাশটির সাথে সেই হ্যাশটির তুলনা করা উচিত।

মাথায় রাখার ধারণাগুলি:

  • আপনার হ্যাশের সাথে কিছু স্কোপ-অনন্য মান মিশ্রিত করে আপনি "লবণ" একটি হ্যাশ, সাধারণত সারি-অনন্য। এর উদ্দেশ্য হ'ল একে অপরের কাছ থেকে স্বতন্ত্রতার গ্যারান্টি দেওয়া যদিও তারা প্রতিনিধিত্ব করে সেই সরলখুলির মানগুলি একই, তাই একই পাসওয়ার্ড সহ দুটি ব্যবহারকারী এখনও আলাদা আলাদা হ্যাশ রাখে have এটি একটি গোপন হিসাবে লবণ হিসাবে বিবেচনা করা অপ্রয়োজনীয়।
  • প্রমাণীকরণ করার সময়, ক্লায়েন্টের কাছ থেকে পাসওয়ার্ড হিসাবে আপনি যে মানটি পাস করেন তা সর্বদা সার্ভার-সাইডে হ্যাশ করুন (এমনকি এটি ইতিমধ্যে হ্যাশ হয়ে থাকলেও) এবং এটি ডাটাবেসে সঞ্চিত প্রাক-হ্যাশ মানটির সাথে তুলনা করুন। এটির জন্য মূল পাসওয়ার্ডের একটি ডাবল-হ্যাশ সংস্করণ সংরক্ষণ করার প্রয়োজন হতে পারে।
  • আপনি যখন একটি হ্যাশ তৈরি করেন, ততক্ষণ অনুসন্ধান সারণিতে কোনও প্রাক-গণিত হ্যাশগুলির সাথে মিল রেখে সুরক্ষার জন্য হ্যাশটিতে একটি সার্ভার / ক্লাস্টার-অনন্য লবনের পাশাপাশি সারি-অনন্য লবণ যুক্ত করার বিষয়টি বিবেচনা করুন।
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.