এটি কি ক্লায়েন্ট পক্ষের পাসওয়ার্ডগুলি হ্যাশ করার পক্ষে মূল্যবান?

132

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

তবে আমার এক বন্ধু আমাকে বলেছিল যে একটি "সফটওয়্যার" পাসওয়ার্ড কোনও নেটওয়ার্ক সফটওয়্যার দ্বারা শুকানো যেতে পারে।

সুতরাং আমার প্রশ্নটি: ক্লায়েন্টের পাশে পাসওয়ার্ড হ্যাশ করা কি ভাল ধারণা? এটি সার্ভারের পাশে হ্যাশ করার চেয়ে ভাল?

passwords client-side hash

— জাকারিয়া
সূত্র

1

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

— ঘূর্ণিঝড়

1

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

— এসএফসিসি

1

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

— তেজয়

5

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

— এমএসএলটাররা

2

এই প্রশ্নটি সিকিউরিটি.স্ট্যাকেক্সচেঞ্জ.কম এ থাকা উচিত নয়?

— efr4k

115

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

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

সার্ভারে:

এলোমেলোভাবে কয়েক বিট উত্পাদন
এই বিটগুলি (স্পষ্ট পাঠ্যে) ক্লায়েন্টকে প্রেরণ করুন

ক্লায়েন্টের উপর:

কয়েকটি এলোমেলো বিট জেনারেট করুন
সংযুক্তি পাসওয়ার্ড, সার্ভারের এলোমেলো বিট এবং ক্লায়েন্টের এলোমেলো বিট
উপরের হ্যাশ উত্পন্ন
সার্ভারে এলোমেলো বিট (স্পষ্ট পাঠ্যে) এবং হ্যাশ জমা দিন

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

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

— ডীর্ক্
সূত্র

5

লগইন সিস্টেমে হ্যাশ পাসওয়ার্ডটি আবার হ্যাশ হওয়ার পরে সে কীভাবে প্রমাণীকরণ করতে পারে?

— জাকারিয়া

4

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

— শির্ক

3

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

— পেসারিয়ার

7

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

— অ্যারোনএলএস

14

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

— এডান

60

প্রথমত, এটি আপনার অ্যাপ্লিকেশনটির সুরক্ষা উন্নত করে না (ধরে নিলে এটি একটি ওয়েব অ্যাপ্লিকেশন)।

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

কেন এটি সহজ। টিএলএস একটি সমস্যা সমাধান করে (যখন কিনে দেওয়া শংসাপত্রগুলির সাথে ব্যবহার করা হয়, স্ব স্বাক্ষরিত নয়) যা ক্রিপ্টোগ্রাফিতে বেশ বড়: আমি যে সার্ভারের সাথে কথা বলছি তা কীভাবে জানব যে আমি যে সার্ভারের সাথে কথা বলছি তা মনে করি? টিএলএস শংসাপত্রগুলি বলার একটি উপায়: "আমি, আপনার ব্রাউজার দ্বারা বিশ্বাসযোগ্য শংসাপত্র কর্তৃপক্ষ, শংসাপত্র দেয় যে [url] এ ওয়েবসাইটটিতে একটি প্রাইভেট কী রয়েছে, যার সাথে একটি প্রাইভেট কী রয়েছে (প্রাইভেট কী) কেবল সার্ভার জানে, দেখুন আমি পুরো দস্তাবেজটিতে আমার স্বাক্ষর সই করেছি, যদি কেউ এটি পরিবর্তন করে তবে আপনি দেখতে পারেন "।

টিএলএস ব্যতীত যে কোনও এনক্রিপশন অর্থহীন হয়ে যায়, কারণ আমি যদি কোনও কফিশপটিতে আপনার পাশে বসে থাকি তবে আমি আপনার ল্যাপটপ / স্মার্টফোনটিকে ভাবতে পারি যে আমি সার্ভার এবং এমআইটিএম (ম্যান ইন দ্য মিডল) আপনি। টিএলএস সহ আপনার ল্যাপটপ / স্মার্টফোনটি "UNTRUSTED CONNECTION" চিৎকার করবে, কারণ আপনার সাইটের সাথে মেলে এমন শংসাপত্রের কর্তৃপক্ষের স্বাক্ষরিত শংসাপত্র আমার কাছে নেই matches (এনক্রিপশন বনাম প্রমাণীকরণ)।

দাবি অস্বীকার: ব্যবহারকারীরা এই সতর্কতাগুলির মাধ্যমে ডানদিকে ক্লিক করুন: "অবিশ্বস্ত সংযোগ? কী? আমি কেবল আমার বিড়ালছানাগুলির ছবি চাই! ব্যতিক্রম যুক্ত করুন নিশ্চিত ক্লিক ক্লিক করুন ! বিড়ালছানা!"

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

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

(SHA256(SHA256(password)+salt))

(ডাটাবেসে লবণকে সরলখরচি হিসাবে সংরক্ষণ করুন)। এবং আপনার পাসওয়ার্ডটি এভাবে প্রেরণ করুন:

RSA_With_Public_Key(SHA256(password))

এবং এইভাবে আপনার পাসওয়ার্ড পরীক্ষা করুন:

if SHA256(RSA_With_Private_Key(SHA256(sent_password))+salt_for_username) == stored_pass: login = ok

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

— FriendlyCryptoNeighbor
সূত্র

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

— নিয়েট

24

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

এটি কিছুটা ভাল, এতে এটি ক্ষতিকারক ব্যবহারকারীকে পাসওয়ার্ড কী তা জানতে বাধা দেয় তবে তারা এখনও লগ ইন করতে পারে (বা সম্ভাব্যভাবে মূল পাসওয়ার্ডটি পুনর্গঠন করতে পারে ), এটি তেমন সহায়ক নয়।

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

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

— dimo414
সূত্র

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

— f1lt3r

17

আসলে আমি একমত নই যে ক্লায়েন্ট সাইড হ্যাশিং এই ক্ষেত্রে আরও সুরক্ষিত। আমি মনে করি এটি কম সুরক্ষিত।

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

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

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

যাইহোক, এই ধরণের প্রশ্নটি সম্ভবত সুরক্ষা স্ট্যাকএক্সচেঞ্জের উপর আরও বিশেষজ্ঞের প্রতিক্রিয়া পাবে।

— অ্যাডাম বারলে
সূত্র

3

এটির সাথে পুরোপুরি একমত কাজ করার জন্য ক্লায়েন্ট-পাশের পদ্ধতির জন্য একজনকেও ক্লায়েন্টের কাছে লবণ প্রেরণ করতে হবে, যা লবণাক্তকরণের পুরো উদ্দেশ্যটিকে অকার্যকর করে দেবে!

— জেমস রাইট

@ জেমস রাইট: পয়েন্টটি প্রতিটি ব্যবহারের জন্য এলোমেলো লবণ প্রেরণ করছে যা লগইন বার্তাগুলির অবৈধ পুনঃব্যবহার রোধ করে। (এক ধরণের রিপ্লে আক্রমণ)। প্রতিবার একই লবণ প্রেরণ করা সত্যই অর্থহীন।

— MSalters

আপনার যা করতে হবে তা হ'ল "ননস" ( en.wikedia.org/wiki/Cryptographic_nonce ) ব্যবহার করা। এইভাবে, সার্ভারটি লবণকে নিয়ন্ত্রণ করে এবং এটি সুরক্ষিত করে। ক্লায়েন্টের পক্ষে হ্যাশ করাও গুরুত্বপূর্ণ, যাতে ইনজেকশন করা জেএস কোডটি পরে এটি সহজে খুঁজে না পায়। এখানে আরো: stackoverflow.com/a/21716654/43615

— টমাস Tempelmann

: একটি লগইন প্রমাণীকরণ প্রক্রিয়ায় লবণ + + আপাতত ব্যবহার জন্য, এই উত্তর দেখার stackoverflow.com/a/24978909/43615

— টমাস Tempelmann

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

— ড্যানিয়েল মেথার

5

নোট করুন যে তৃতীয় পক্ষের পক্ষের বিরুদ্ধে পাসওয়ার্ডগুলি সুরক্ষিত রাখা কেবল সেখানে নেই।

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

অতএব, ক্লায়েন্ট-সাইডে হ্যাশিং / এনক্রিপ্ট করা অর্থবোধ করে।

— রাফায়েল
সূত্র

একমত! অনেক লোক এই বিষয়টিকে মিস করে। আমি যদি আপনার সল্টযুক্ত হ্যাশ পাসওয়ার্ডগুলির পাসওয়ার্ডের ডেটাবেস ডাউনলোড করি এবং আমি হ্যাশ লুকিং ডেটাবেস ব্যবহার করে কেবল একটিকে ক্র্যাক করতে পারি, তবে সম্ভাবনাগুলি হ'ল আমি সেগুলি ক্র্যাক করতে পারি। আমার কাছে একবার 50k আসল পাসওয়ার্ড পরে, আমার কাছে এখন পরিষেবাগুলিতে xব্যবহারকারীদের কী রয়েছে nযা কেবলমাত্র সার্ভারে এনক্রিপ্ট করে। যদি প্রতিটি পরিষেবা ক্লায়েন্টটি ছাড়ার আগে পাসওয়ার্ডটিকে স্বতন্ত্রভাবে হ্যাশ করে তবে ক্রস-পরিষেবা পাসওয়ার্ডের বৃহত ডাটাবেসটি অনেক বেশি, আরও ছোট হয়। আপনার AWS লগইন ট্র্যাফিক চেক করুন, দেখুন তারা কী করে। এটা আমার প্রিয় ওয়াটসন সম্ভাবনা।

— f1lt3r

3

এটি নির্ভর করে, আপনি ক্লায়েন্ট সাইড হ্যাশিং ব্যবহার করতে পারেন, তবে সার্ভার সাইড লবণ সম্ভব হবে না।

ক্লায়েন্টের পাশে পাসওয়ার্ড এনক্রিপশন লিঙ্কটি দেখুন

— SmAxlL
সূত্র

1

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

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

এর মেজর সুবিধাটি হ'ল আমার সার্ভার / ডেটা স্টোরটিতে আনইনক্রিপ্ট করা মেমরিতে এমনকি ব্যবহারকারীদের ডেটা সংরক্ষণ / রাখার দরকার নেই (এবং আমার সার্ভারের ব্যক্তিগত কী শারীরিকভাবে পৃথক)

এর ভিত্তি হ'ল জনগণকে সুরক্ষিতভাবে যোগাযোগের একটি উপায় প্রদান করা যেখানে এইচটিটিপিএস সীমাবদ্ধ ছিল (যেমন, ইরান / এন। কোরিয়া atc ...) এবং কেবল একটি মজাদার পরীক্ষা।

আমি প্রথম থেকেই এ সম্পর্কে চিন্তা করি, http://www.mailvelope.com/ এটি ব্যবহার করে

— ScottGal
সূত্র

1

যদি কেউ আপনার সংযোগে ডেটাটি ইন-আউট দেখতে পারে তবে প্রমাণীকরণ আপনাকে সংরক্ষণ করবে না। পরিবর্তে আমি সুপার সিক্রেট স্টাফের জন্য নিম্নলিখিতগুলি করব।

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

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

ব্যবহারকারীদের ডেটা ব্রাউজারের পাশেও এনক্রিপ্ট করা আছে।

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

এই দুটি পদ্ধতির কয়েকটি ছোট উদাহরণ আমার ব্লগে http://glynrob.com/javascript/client-side-hashing-and-encryption/

— GlynRob
সূত্র

1

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

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

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

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

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

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

— এরিক টোলেগার
সূত্র

ঠিক আমার উদ্বেগ। দুর্বল প্রয়োগ বা দূষিত অভিপ্রায় কারণে যদি সার্ভারটি কোনওভাবে দুর্ঘটনাক্রমে লগ হয়, তবে পাসওয়ার্ড পুনরায় ব্যবহার করা হলে ব্যবহারকারীর অন্যান্য অ্যাকাউন্টের সাথে আপস করা সম্ভব।

— ড্যান

0

এই বিবেচনা:-

ক্লায়েন্ট সার্ভারে অনুরোধ পাঠায় "আমার কাছে বৈধতা দেওয়ার জন্য একটি পাসওয়ার্ড রয়েছে"।

সার্ভার ক্লায়েন্টকে এককালীন কেবল এলোমেলো স্ট্রিং প্রেরণ করে। আর $

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

ক্লায়েন্ট সার্ভারে স্ট্রিং প্রেরণ করে এবং পাসওয়ার্ড ঠিক আছে, সার্ভার ব্যবহারকারীকে লগ ইন করে।

সার্ভারের আর $ ব্যবহার করে অন্য একটি লগইন অনুরোধটি গ্রহণ করা উচিত, ব্যবহারকারী লগ আউট এবং অ্যাকাউন্টটি হ'তে থাকা মুলতুবি তদন্ত।

স্পষ্টতই অন্যান্য সমস্ত (স্বাভাবিক) নিরাপত্তা সতর্কতা অবলম্বন করা হবে।

— cneeds
সূত্র

0

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

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

— n8isjack
সূত্র