কীভাবে ব্যবহারকারীর পাসওয়ার্ডগুলি লিনাক্সে স্পষ্ট পাঠ্য হিসাবে দেখানো যায়?

Question

আমরা জানি যে ব্যবহারকারীর পাসওয়ার্ডগুলি সেভ করা হয়েছে /etc/passwd, তবে একটি এনক্রিপ্ট করা উপায়ে, সুতরাং এমনকি রুট এগুলি দেখতে পাবে না:

jane:x:501:501::/home/jane:/bin/bash
fred:x:502:502::/home/fred:/bin/bash

উপরে প্রদর্শিত হিসাবে, :x:পাসওয়ার্ড প্রতিনিধিত্ব করে।

/etc/passwdপরিষ্কার লেখায় পাসওয়ার্ড সংরক্ষণ করার জন্য কি কোনও উপায় (সম্ভাব্য কনফিগারেশন) রয়েছে এবং রুটগুলি সেগুলি দেখতে পারে?

Comments

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

— হ্যালোসহোস্ট

আমি এই সম্পর্কে শুধু কৌতূহল করছি, কেন প্রশাসনের প্রশাসক (মূল) অন্যান্য ব্যবহারকারীর পাসওয়ার্ড দেখতে পাচ্ছেন না?

— ব্যবহারকারী 78050

@ ব্যবহারকারী 80৮০৫০ কারণ মূল ব্যবহারকারীর অন্যান্য ব্যবহারকারীর পাসওয়ার্ড জানার কোনও কারণ নেই এবং তাদের এটি করার অনুমতি দেওয়ার জন্য এটি একটি বড় সুরক্ষা ঝুঁকি হবে।

— ডেভিড জেড

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

— হ্যালোগোস্ট

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

— ক্রিশ্চিয়ান সিউপিতু

Answer 1

অন্য দুটি উত্তর বলেছি আপনি-সঠিকভাবে! -অর্থাৎ এই একটি খারাপ ধারণা ™ । তবে তারা আপনাকে এটি করা কঠোরভাবে বলেছে , প্রয়োজন একটি গোছা প্রোগ্রামের পরিবর্তন।

এটা সত্যি না. এটা খুব সহজ. আপনার কেবল এক বা দুটি কনফিগারেশন ফাইল পরিবর্তন করতে হবে। এটি উল্লেখ করা আমার পক্ষে গুরুত্বপূর্ণ মনে হচ্ছে কারণ আপনি নিয়ন্ত্রণ করেন না এমন সিস্টেমে লগ ইন করার সময় আপনার এটি সম্পর্কে সচেতন হওয়া উচিত। এগুলি আসলে একটি সরল-পাঠ্য পাসওয়ার্ড রাখবে না /etc/passwdবা /etc/shadow, এটি অন্য কোনও ফাইলে যাবে। দ্রষ্টব্য আমি এগুলি পরীক্ষা করিনি, কারণ আমার পাসওয়ার্ডটি সরল পাঠ্যে না রাখাই।

1. সম্পাদনা /etc/pam.d/common-password(পাসওয়ার্ড ধরার জন্য চেঞ্জ করা হয়েছে) বা /etc/pam.d/common-auth(লগইন করতে ধরা) এবং এড করুন… pam_exec expose_authtok log=/root/passwords /bin/cat

2. এগুলির দুটিই সম্পাদনা করুন এবং পাম_উনিক্স থেকে পাম_উসারডবিতে স্যুইচ করুন crypt=none। বিকল্পভাবে, আপনি কেবলমাত্র পাসওয়ার্ড পরিবর্তন করার সময় এটি রেকর্ড করতে সাধারণ-পাসওয়ার্ডে (পাশাপাশি পাম_উনিক্স রেখে) রেখে দিতে পারেন।

3. আপনি ভাগ পারে shadowছায়া ফাইল নিষ্ক্রিয় করতে pam_unix থেকে (সেইসাথে শক্তিশালী হ্যাশ অপশন) বিকল্প, এবং ঐতিহ্যগত সমাধিগৃহ পাসওয়ার্ড ফিরে যান। সাধারণ পাঠ্য নয়, তবে জন দি রিপার আপনার জন্য এটি ঠিক করবে।

আরও তথ্যের জন্য, প্যাম সিস্টেম অ্যাডমিন গাইড পরীক্ষা করুন ।

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

Comments

আমি মনে করি যে সরল পাঠ্য পাসওয়ার্ডগুলিতে লিখিত আছে /root/passwords।

— ফাহিম মিঠা

BTW। এটি কতটা সহজ তা জেনে খুব ভাল এবং কোনও আপোষমূলক সিস্টেমের ভয়ে থাকলে আমাকে কোথায় দেখতে হবে।

— এরিক

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

— ডারোবার্ট

এটি বরং ধরে নিচ্ছে যে ডিস্ট্রো প্যাম ব্যবহার করছে, কোনওভাবেই তারা সবাই করে না।

— মান

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

— ought

Answer 2

ওহে প্রিয়, ঠিক আছে, শুরুতে শুরু করা যাক ...

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

না, তারা সঞ্চিত হয়েছে যে /etc/passwd, এবং যে বেশ কিছু সময়ের আগে। বর্তমানে পাসওয়ার্ডগুলি বেশিরভাগ সময় তথাকথিত ছায়া ফাইলে সংরক্ষণ করা হয়/etc/shadow ।

তবে একটি এনক্রিপ্ট করা উপায়ে, যাতে রুটগুলি তাদের দেখতেও পায় না:

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

ছায়া ফাইলের পাসওয়ার্ডগুলি হ্যাশ হিসাবে সংরক্ষণ করা হয়।

উপরে প্রদর্শিত হিসাবে: এক্স: পাসওয়ার্ড উপস্থাপন

xএই ক্ষেত্রে শুধুমাত্র উত্তরাধিকার পাসওয়ার্ড ক্ষেত্রের জন্য একটি স্থানধারক হয়। এর xমানে হল যে ছায়া ফাইলটিতে পাসওয়ার্ড পাওয়া যাবে।

/ / Etc / পাসডাব্লুডে পাসওয়ার্ডটি পরিষ্কার লেখায় এবং রুটগুলি দেখতে পারে এমন কোনও পাসওয়ার্ড সংরক্ষণ করার জন্য কি কোনও উপায় (সম্ভাব্য কনফিগারেশন) রয়েছে?

হ্যাঁ, এটি সত্যই সম্ভব, তবে কিছু কারণে এটি ভাল ধারণা নয়। ডেরোবার্টের উত্তর এটি করার একটি সহজ উপায় ব্যাখ্যা করে ।

তবে কেন এটি একটি ভাল ধারণা নয়? ভাল, একটি সাধারণ তবে খুব গুরুত্বপূর্ণ কারণে: সুরক্ষা। আমি এই প্রশ্নগুলি পড়ার পরামর্শ দিই:

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

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

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

Comments

এনক্রিপশন এবং হ্যাশিং সম্পর্কিত ওপি'র প্রতিরক্ষা হিসাবে, গ্লিবসি থেকে ক্রিপ্ট ম্যান পৃষ্ঠাটি বলে: salt লবণ যদি অক্ষর "$id$"দ্বারা শুরু হওয়া একটি অক্ষরযুক্ত স্ট্রিং থাকে যারপরে একটি স্ট্রিং দ্বারা সমাপ্ত হয় "$": $id$salt$encrypted তবে ডিইএস মেশিনটি ব্যবহার না করে, ব্যবহৃত এনক্রিপশন পদ্ধতি idচিহ্নিত করে এবং তারপরে কীভাবে বাকী স্ট্রিংটি ব্যাখ্যা করা হয় তা নির্ধারণ করে »

— ক্রিশ্চিয়ান সিউপিতু

আকর্ষণীয়, তবে মূল প্রশ্নের উত্তর দেয় না, যেমন ডার্বার্টের উত্তর দেয়।

— এরিক

@ এরিক কখনও কখনও কোনও প্রশ্নের সঠিক উত্তর হ'ল "এটি করবেন না", এমনকি জিনিসটি প্রযুক্তিগতভাবে সম্ভব হলেও। এটি সেই সময়ের এক।

— গিলস 'দুষ্ট হওয়া বন্ধ করুন'

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

— ডারোবার্ট

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

— মাইকেল ডারস্ট

Answer 3

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

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

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

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

আরও আকর্ষণীয় বিষয় থাকতে হবে, আপনার সিস্টেমে কাজ করার বিষয়টি অনুসন্ধান করা যেতে পারে।

Comments

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

— গিলস 'দুষ্ট হওয়া বন্ধ করুন'

@ গিলিস আমি কেবল ওপিএস পরিভাষা পুনরায় ব্যবহার করেছি, তবে আপনি ঠিক বলেছেন যে হ্যাশ একটি আরও উপযুক্ত শব্দ।

— অ্যান্থন

Answer 4

এর মূল কারণ (এটি কেন খারাপ ধারণা) এটি হ'ল কোনও ব্যবহারকারীর (রুট, অ্যাডমিন বা অন্যান্য) কখনও অন্যের ব্যবহারকারীর পাসওয়ার্ড অ্যাক্সেস করা উচিত নয়।

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

সেই ব্যবহারকারী হিসাবে লগ ইন করার সময় আমি যে কোনও ক্রিয়াকলাপ করি তা অন্য ব্যবহারকারীকে দায়ী করা হবে held এবং এটি প্রমাণীকরণের কাজ করা উচিত নয়।

ক্রিয়াগুলি বিপর্যয়কর হতে পারে, যেমন গুরুত্বপূর্ণ ফাইলগুলির পুরো গোছা মুছে ফেলা, হার্ড ডিস্কগুলি মুছে ফেলা, ব্যাকআপগুলি মুছে ফেলা, পারমাণবিক শক্তি পরিকল্পনা বন্ধ করা ইত্যাদি etc.

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

তারপরে আমি বাহামায় দীর্ঘ ছুটিতে যাই ...

---

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

এবং @ মিরালের মন্তব্য ^{* হিসাবে} , এর ব্যতিক্রম রয়েছে suযা ছদ্মবেশকরণের অনুমতি দেওয়ার সময় (এবং উপরের যুক্তিটি ধরণের ধাক্কা দেয়) এছাড়াও এর ব্যবহারের লগ রাখে (সুতরাং এটি নিয়মকে "শুধুমাত্র প্রশাসকরা অন্যের ছদ্মবেশ তৈরি করতে পারে তবে একটি লগ রাখা হয় ")।

^{* ব্যাঙ্কের উদাহরণটি সম্ভবত সেরা ছিল না। যে কোনও পরিবেশে যেখানে সুরক্ষা গুরুত্বপূর্ণ, সেখানে কেবলমাত্র একটি পাসওয়ার্ডের চেয়ে বেশি প্রমাণীকরণ ও অনুমোদনের উপায় প্রয়োজন।}

Comments

এই যুক্তিটির একটি ত্রুটি হ'ল রুট ব্যবহারকারীরা যে কোনও উপায়ে তাদের পাসওয়ার্ড না জেনে সিস্টেমে অন্য কোনও ব্যবহারকারীর ছদ্মবেশ তৈরি করতে পারে। যত সহজ su otheruser।

— মিরাল

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

— ypercubeᵀᴹ