পাসওয়ার্ড পুনরায় ব্যবহারের বিরুদ্ধে "সুরক্ষা" হিসাবে কেন জমা দেওয়ার আগে ক্লায়েন্টে প্রায় কোনও ওয়েবপৃষ্ঠা হ্যাশ পাসওয়ার্ড নেই?


46

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

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


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

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

2
@ জারোদ - এটি আমার কাছে মনে হয়েছে, যদিও বিভিন্ন ক্লায়েন্ট-সাইড হ্যাশিং অ্যালগরিদম ব্যবহার করে বিভিন্ন ওয়েব সাইটগুলি সেই কমিকের দ্বারা বর্ণিত আক্রমণটিকে আটকাতে পারে। একটি বিস্তৃত পুনরায় ব্যবহৃত পাসওয়ার্ড সেই ভিন্ন ভিন্ন হ্যাশ অ্যালগরিদমের মাধ্যমে অনেকগুলি ভিন্ন পাসওয়ার্ড হয়ে যায়। সেই ক্লায়েন্ট-সাইড হ্যাশ গণনা অন্যান্য ধরণের সুরক্ষা প্রয়োগ করা বাধা দেয় না - যেমন কোনও সুরক্ষিত সংযোগের মাধ্যমে হ্যাশ পাঠানো।
স্টিভ 314

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

5
মনে হচ্ছে দুর্বৃত্ত সাইটগুলি থেকে নিজেকে রক্ষা করার জন্য আপনার পরিকল্পনাটি দুর্বৃত্ত সাইটগুলিকে আরও ভাল সুরক্ষা স্থাপনের জন্য বলা। ?
pc1oad1etter

উত্তর:


46

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


2
এটি এখন পর্যন্ত সেরা উত্তর।

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

2
আমি মনে করি পাসওয়ার্ডের ক্লায়েন্ট-সাইডটি সুরক্ষা যোগ করে add আমি যদি শুনছি তবে আমি কেবলমাত্র আপনার হ্যাশ দেখতে পাচ্ছি, আপনার পাসওয়ার্ড নয়। যদি সার্ভার কোনও চ্যালেঞ্জ প্রেরণ করে (যেমনটি করা উচিত) হ্যাশ এমনকি পুনরায় ব্যবহারযোগ্য নয়।
Andomar

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

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

14

তত্ত্বগতভাবে এটি কোনও অতিরিক্ত সুরক্ষা দেয় না, তবে বাস্তবে এটি "দুর্বৃত্ত সাইটগুলি" রক্ষা করতে ব্যবহার করা যেতে পারে যা সার্ভারে আপনার পাসওয়ার্ড হ্যাশ করে না।

কীভাবে এটি আপনাকে সুরক্ষা দেয়? দেখে মনে হচ্ছে আপনি যা করতে চান তা হ্যাশ পাসওয়ার্ড যা অর্থহীন is কারণ হ্যাশ পাসওয়ার্ড তখন পাসওয়ার্ডে পরিণত হত।

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

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

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


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

2
যদি এটি ক্লায়েন্টের উপরে থাকে তবে এটি আপোস করা হয়, ক্লায়েন্টের উপর কোনও লবণ সরল দৃষ্টিতে থাকে, এটি একটি অযৌক্তিক প্রশ্ন। যদি আপনি @ রামহাউন্ডের উত্তরটি বুঝতে না পারেন তবে আপনার সুরক্ষিত হওয়া কোডটি লেখা উচিত নয় এবং শুরু থেকে সুরক্ষা এবং ক্রিপ্টোগ্রাফিটি পড়া শুরু করুন।

3
আপনি যখন মূল পোস্টারটি উদ্ধৃত করছেন, অনুগ্রহ করে পাঠ্যটি ফর্ম্যাট করুন (পাঠ্যটি নির্বাচন করুন এবং সম্পাদকের ঠিক উপরে উদ্ধৃতি আইকনটি ব্যবহার করুন)
মার্জন ভেনেমা

1
জারোদ, আপনার হাস্যকর দাবি করার আগে দয়া করে আপনার নিজের পরামর্শ অনুসরণ করুন এবং নিজেকে কিছুটা অবহিত করুন। মাঝারি আক্রমণে থাকা কোনও ব্যক্তি যুক্তিসঙ্গত লবণের দৈর্ঘ্য সহ সুরক্ষিত হ্যাশ ফাংশনের বিরুদ্ধে অকেজো। এবং আমার পরামর্শটি কোনওভাবেই 'অস্পষ্টতার দ্বারা সুরক্ষা' নয়, এটি বর্তমানে এই ক্ষেত্রের বিশেষজ্ঞদের দ্বারা যা জানা এবং গ্রহণ করা হয়েছে তার ভিত্তিতে এটি নিরাপদ এবং এটি অনেকগুলি প্রোটোকলে একইভাবে ব্যবহৃত হয় way এটি আমার আবিষ্কার নয়, আমি কেবলমাত্র একটি ওয়েবসাইট লগইনে একটি ভাল বোঝা পদ্ধতি প্রয়োগ করেছি। আপনার মিথ্যা অনুমানগুলি সত্য যে তারা অন্য অনেকের দ্বারা ভাগ করে নেওয়া হয়েছে তা দ্বারা কোনও পদার্থ লাভ করে না।
x4u

3
যদি নুনটি ক্লায়েন্টের দ্বারা জানা থাকে এবং এটি কোনও সার্ভার থেকে পরিষ্কার করে প্রেরণ করা হয় তবে মাঝের কিছু এটিও জানে। কখনও বলেনি, আমার হ্যাশটি পূর্বাবস্থায় নেওয়ার দরকার ছিল, যদি আপনি ক্লায়েন্টের উপর লবণ জানেন তবে নিরাপদ নয়।

11

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

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

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


3
এটি সেরা উত্তর। আপনার ট্রান্সপোর্ট লেয়ারে এনক্রিপ্ট করা উচিত। এটি না করে, বাকিগুলি নিরাপদ নয়। হ্যাঁ, আপনি কোনও এনক্রিপশন ফাংশন লিখতে পারেন ... তবে সেই ফাংশনটি (দূষিত) শেষ ব্যবহারকারীদের কাছে দৃশ্যমান হবে। এসএসএল ব্যবহার করুন।
pc1oad1etter

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

6

সমাধানটি এর চেয়ে সহজ। ক্লায়েন্ট শংসাপত্র। আমি আমার মেশিনে একটি ক্লায়েন্ট শংসাপত্র তৈরি করি। আমি যখন কোনও ওয়েবসাইটের সাথে নিবন্ধন করি তখন আমরা আমার ক্লায়েন্টের শংসাপত্র এবং সার্ভারের শংসাপত্র ব্যবহার করে একটি হ্যান্ডশেক করি।

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

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

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

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

যদিও OAuth সঠিক দিকের এক ধাপ।


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

5

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

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

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

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

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


2
গৃহীত উত্তরগুলি আপনার পয়েন্টটি বেশ ভালভাবে ভাগ করে দেয়। যদিও "সর্বাধিক উত্তরগুলি" দেয় না এবং কারণ আপনার উত্তরটি সত্যই খুব বেশি মূল্য দেয় না, এই প্রশ্নটি পুনরুত্থানের কোনও মানে নেই।
ফ্রাঙ্ক

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

@ পড়ার বিরক্ত করতে খুব দীর্ঘ হওয়ায় গ্রহণযোগ্য উত্তর সীমানাগুলি খুলুন। এটি কীভাবে এটি বাস্তবায়িত করা যায় এবং কীভাবে শেষের দিকে সুবিধাগুলি ঝাঁকিয়ে যায় সে সম্পর্কে খুব বেশি বিস্তারিতভাবে যায়। একটি আলাদা উত্তরে টিএল; ডিআর থাকা উপকারী।
জুলস

2
@ জুলস: এজন্য সম্পাদনা বিদ্যমান।
রবার্ট হার্ভে

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

1

এটি অবশ্যই সম্ভব, এবং আসলে আপনার কোনও ওয়েবসাইটের জন্য অপেক্ষা করার দরকার নেই।

কটাক্ষপাত আছে SuperGenPass । এটি একটি বুকমার্কলেট।

এটি কেবল পাসওয়ার্ড ক্ষেত্রগুলি স্বীকৃতি দেয়, ওয়েবসাইট ডোমেন দিয়ে আপনি কী টাইপ করেন তা কনটেট করে, এটি হ্যাশ করে, কিছুটা ম্যাঙ্গাল করে যাতে পাসওয়ার্ডে কেবলমাত্র "ভর্তি" অক্ষর পাওয়া যায় এবং কেবল তখনই আপনার হ্যাশ-পাসওয়ার্ডটি তারে প্রেরণ করা হয়।

প্রক্রিয়াতে সাইট ডোমেন ব্যবহার করে, আপনি এইভাবে সাইট প্রতি অনন্য পাসওয়ার্ড পাবেন, এমনকি যদি আপনি সর্বদা একই পাসওয়ার্ডটি পুনরায় ব্যবহার করেন তবে।

এটি চূড়ান্তভাবে সুরক্ষিত নয় (বেস 64-MD5), তবে আপনি যদি চান তবে আপনি নিখুঁতভাবে একটি শ -2 ভিত্তিক বাস্তবায়ন বিতরণ করুন।

কেবলমাত্র নেতিবাচক দিকটি যদি ডোমেন পরিবর্তন হয় তবে এক্ষেত্রে আপনাকে ওয়েবসাইটটি আপনার পাসওয়ার্ডটি পুনরায় সেট করতে বলা উচিত কারণ আপনি নিজের দ্বারা এটি পুনরুদ্ধার করতে পারবেন না ... যদিও এটি প্রায়শই ঘটে না, তাই আমি এটিকে বিবেচনা করি গ্রহণযোগ্য বাণিজ্য বন্ধ।


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

3
ক্লিয়ারে পাসওয়ার্ডটি পাস করা অন্য কোনও স্কিমের তুলনায় এটি আর সুরক্ষিত নয়। এটি পাসওয়ার্ডটিকে অনন্য করে তোলে তবে এটি এখনও এনক্রিপ্ট করা হয়নি তবে আমার মাঝখানে যদি একটি সার্ভার থাকে তবে আমি কেবল জটিল তবে পরিষ্কার পাসওয়ার্ডটি ধরতে পারি এবং এটি যতটা চাই ব্যবহার করতে পারি, এটি পরিবর্তন হয় না। একটি হ্যাশ কিছু ম্যাজিক বুলেট নয়, এটি এমনকি এনক্রিপশনও নয়, তাদেরকে ক্রিপ্টোগ্রাফিক হ্যাশ বলা হয়, তবে এর অর্থ এই নয় যে তারা এনক্রিপশন are আমার পাসওয়ার্ডটি passwordবা passwordক্লায়েন্টের কাছে জানা কিছু লবণ সহ কোনও SHA-256 আছে কিনা তা বিবেচনা করে না, মাঝের সংযুক্তির কোনও ব্যক্তি এটি ক্যাপচার করতে পারে।

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

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

6
@ জারোদ: এটি সাইটের জন্য কোনও সুরক্ষা ব্যবস্থা নয় , এটি ব্যবহারকারীর জন্য সুরক্ষা ব্যবস্থা । প্রত্যেকে যদি এই জাতীয় স্কিম ব্যবহার করে তবে পাসওয়ার্ড পুনঃব্যবহার করা হবে না-ইস্যু be একটি এমআইটিএম স্কিম সেই সাইটে অ্যাক্সেস পেতে ক্লায়েন্ট-হ্যাশ পাসওয়ার্ডটি ব্যবহার করতে পারে তবে কেবলমাত্র সেই সাইটে। সেখানেই উন্নতি নিহিত। সাধারণত আপনি কেবল একটি পাসওয়ার্ড ক্র্যাক করে প্রচুর অ্যাকাউন্টে অ্যাক্সেস অর্জন করতে পারবেন বলে আশা করতে পারেন , কারণ সেই পাসওয়ার্ডটি পুনরায় ব্যবহারের সম্ভাবনা রয়েছে; এই ক্ষেত্রে, কর্কশ পাসওয়ার্ড কার্যত শুধুমাত্র সাইট বা ডাটাবেসের মধ্যে পাওয়া যায়নি জন্য বৈধ বলে নিশ্চিত করা হয়।
Aaronaught

0

আমি এক্স 4 এর উত্তর পছন্দ করি তবে আমার মতে এটির মতো কিছু ব্রাউজারে / এইচটিএমএল স্পেসিফিকেশনে সংহত করা উচিত - এই মুহুর্তে এটির উত্তর মাত্র অর্ধেক।

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

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

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

ব্যবহারকারীর জানতে হবে যে তাদের পাসওয়ার্ড এমনকি সার্ভারে প্রেরণ করার জন্য উপলব্ধ নয় - কেবল হ্যাশ। বর্তমানে এমনকি এক্স 4 ইউ এর সমাধান ব্যবহার করে তাদের জানার উপায় নেই কারণ এটি প্রযুক্তি ব্যবহার করছে কিনা তা আপনি জানেন না।


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

-1

আমার মনে হয় ফ্রেমওয়ার্ক, সিএমএস, ফোরাম সফ্টওয়্যার ইত্যাদির মতো কিছু তৈরি করার সময় এটি ব্যবহার করার একটি ভাল পদ্ধতি, যেখানে আপনি যে সার্ভারগুলি ইনস্টল করা থাকতে পারে সেগুলি নিয়ন্ত্রণ করেন না। হ্যাঁ, হ্যাঁ, আপনার লগইন এবং লগ-ইন করা ক্রিয়াকলাপের জন্য সর্বদা এসএসএল ব্যবহারের পরামর্শ দেওয়া উচিত তবে কিছু ফ্রেম আপনার ফ্রেমওয়ার্ক / সিমি ব্যবহার করে না, তাই তারা এখনও এ থেকে উপকৃত হতে পারে।

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

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

অন্যরা পরামর্শ দিয়েছে যে ব্যবহারকারীরা তাদের ব্যবহার করা প্রতিটি সাইটের জন্য অনন্য পাসওয়ার্ড তৈরি করতে হবে বা পাসওয়ার্ড পরিচালকদের ব্যবহার করা উচিত। যদিও এটি তত্ত্বের দৃ in় পরামর্শ, আমরা সকলেই জানি সত্যিকারের বিশ্বে নির্ভর করা বোকামি। এই যে কোনও একটি ব্যবহারকারীর শতাংশ শতাংশই কম এবং আমি সন্দেহ করি যে খুব শীঘ্রই যে কোনও সময় পরিবর্তন হবে।

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

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