কনফিগারেশ ফাইলগুলিতে পাসওয়ার্ডগুলি পরিবেশের ভেরিয়েবল (প্লেইন পাঠ্যের চেয়ে) হিসাবে সংরক্ষণ করা কি নিরাপদ?

Question

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

আমার এক সহযোগীর সাথে এটি নিয়ে আলোচনার সময় তিনি পরামর্শ দিয়েছিলেন যে এটি একটি দুর্বল অনুশীলন - সম্ভবত এটি সম্ভবত এটি এতটা নিরাপদ নয় যেটি প্রথমে মনে হয়।

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

Answer 1

আরও তাত্ত্বিক স্তরে, আমি নিম্নলিখিত উপায়ে (ক্রমবর্ধমান শক্তি অনুসারে) সুরক্ষার স্তরের বিষয়ে চিন্তাভাবনা করি:

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

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

Comments

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

— জন কার্টার

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

— গণিত

Answer 2

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

ফাইলগুলিতে আপনার পাসওয়ার্ডগুলি সংরক্ষণ না করে সংস্করণ নিয়ন্ত্রণ সিস্টেমে সংরক্ষণ করা অসম্ভব করে তোলে।

Comments

সংস্করণ নিয়ন্ত্রণে গোপন কনফিগারেশন সেটিংস সংরক্ষণ না করার জন্য একটি দুর্দান্ত যুক্তিসঙ্গত বিকল্প সেগুলি সংস্করণের নিয়ন্ত্রণ সংগ্রহস্থলে বা কোডের জন্য সংগ্রহস্থল থেকে পৃথক প্রকল্পে সংরক্ষণ করা হয়।

— কেনি এভিট

@ কেনিএভিট এখনও কোনও ভাগ করা স্থানে সুরক্ষিত, সরল পাঠের পাসওয়ার্ড ছেড়ে দেয় যা ভান্ডারটিতে অ্যাক্সেস থাকা যে কেউ খুঁজে পেতে পারে এবং কে এটি অ্যাক্সেস করেছে তা ট্র্যাক করার কোনও উপায় নেই।

— ফিস্টঅফফুরি 13

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

— কেনি এভিট

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

— ব্রায়ান ক্লাইন

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

— অমিত নাইডু

Answer 3

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

Comments

পরিবেশের ভেরিয়েবলের জন্য, আমি এখানে ইউনিক্সের আশা করছি ... পরিবেশের ভেরিয়েবলগুলি ফাইলের চেয়ে কম সুরক্ষিত। যে কোনও চলমান প্রক্রিয়ার পরিবেশ পরীক্ষা করতে পারে তবে ফাইলগুলির কমপক্ষে এসিএল থাকতে পারে।

— ভ্যাটাইন

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

— পিটার নিক্সে

@ ভ্যাটাইন স্থানগুলি পরিবেশের ভেরিয়েবলের বহিঃপ্রকাশের অনুমতিও রয়েছে। cat /proc/1/environউদাহরণস্বরূপ চেষ্টা করুন ।

— ক্রিস ডাউন

@ ভ্যাটাইন সত্যি? আমার নিজস্ব মালিকানাধীন প্রক্রিয়াগুলির কোনও পরিবেশ আমি দেখতে পাচ্ছি না ps axe। strace -e open ps axeদেখায় যে এটি এই তথ্যটি পেয়েছে /proc/[pid]/environ, যার অনুমতি প্রয়োগ রয়েছে (অতএব এটি একটি গুচ্ছ open("/proc/19795/environ", O_RDONLY) = -1 EACCES (Permission denied))।

— ক্রিস ডাউন

হাহ। এটি দেখুন, একটি সমস্যা অবশেষে সংশোধন করা হয়েছে (ব্যবহৃত হত যা নির্ধারিত psছিল এবং আনন্দের সাথে আপনাকে বেশ কয়েকটি কিছুর পরিবেশ প্রদর্শন করবে)।

— ভ্যাটাইন

Answer 4

দুঃখিত, মন্তব্য করার মতো পর্যাপ্ত পরিমাণ আমার কাছে নেই, তবে আমি এটিও যুক্ত করতে চেয়েছিলাম যদি আপনি যত্নবান না হন তবে আপনার শেলটিও এই কমান্ডের ইতিহাসে সেই পাসওয়ার্ডটি ক্যাপচার করতে পারে। সুতরাং $ pwd=mypassword my_progম্যানুয়ালি এমন কিছু চালানো ততটা ছড়িয়ে নেই যতটা আপনি আশা করেছিলেন।

Comments

আপনি যদি কোনও স্থান দিয়ে পুরো "env var + কমান্ড" উপস্থাপন করেন, তবে এটি ইতিহাসে সঞ্চিত হয় না

— shadi

ধন্যবাদ @ শাদি। প্রতিদিন নতুন কিছু শিখুন! আমি অবাক হয়েছি যে শেলটি নির্দিষ্ট / বন্ধ করা সহজ বা যদি এমন কিছু হয় যা বেশ ধারাবাহিকভাবে আশা করা যায়?

— bianclements

আর একটি উপায় হ'ল ব্যবহার করা read -s MY_PASS_VARযা শেল-ইতিহাস অনুসন্ধান এবং কাঁধে সার্ফার উভয় থেকে রক্ষা করবে।

— ম্যাট্রিক্সম্যানএটিআইআরসেবা

@ ব্রায়ানলেমেন্টস আমি যোগ করতে চাই যে একটি কমান্ডের সাথে পূর্ববর্তী তৈরি করা কেবলমাত্র একটি শর্তের সাথে যদি বর্তমান শেলটি HISTCONTROLসেট করা থাকে ignorespaceবা ignorebothপ্রযুক্তিগতভাবে এটি চালু / বন্ধ করা যায় তবেই কাজ করে।

— মোশি

Answer 5

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

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

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

যদি আপনার শংসাপত্রগুলি কোনও ফাইলে থাকে তবে তার মধ্যে পিকিং করা আরও শক্ত।

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

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

Comments

"1 একটি লাইব্রেরির লেখক স্ট্যাক ট্রেস প্লাস ENV ভেরিয়েবলগুলি ডিবাগিংয়ের জন্য তাদের ইমেল করতে পারে" এর জন্য +1। এই পরিস্থিতি সম্পর্কে কখনও ভাবেননি।

— নেটিশিক্স

Answer 6

এটি আপনার হুমকির মডেলের উপর নির্ভর করে।

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

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

ব্যক্তিগতভাবে, আমি মনে করি যে অবহেলিত ব্যবহারকারীরা প্ররোচিত বিরোধীদের চেয়ে বেশি সাধারণ, তাই আমি পরিবেশের পরিবর্তনশীল পদ্ধতির সাথে যাব।

Answer 7

আফ্রিকান, দুটি কারণের কারণে মানুষ পরিবেশের ভেরিয়েবলগুলিতে গোপনীয়তা সংরক্ষণের পরামর্শ দেয়:

1. অজ্ঞাতসারে কোনও রেপোতে গোপন ফ্ল্যাট ফাইলগুলি সংঘবদ্ধ করা খুব সহজ। (এবং এটি যদি সর্বজনীন রেপো হয় তবে আপনি টোস্ট।
2. এটি পাসওয়ার্ড বিশৃঙ্খলা প্রতিরোধ করে অর্থাত্‍, বিভিন্ন প্রকল্পের ডিরেক্টরি ফাইলগুলিতে একই কী থাকা নিজেই একটি সুরক্ষা ঝুঁকি কারণ অবশেষে বিকাশকারীরা কোথায় সিক্রেটস রয়েছে তা ট্র্যাক হারিয়ে ফেলবে।

এই দুটি সমস্যা আরও ভাল উপায়ে সমাধান করা যেতে পারে। প্রাক্তনটির একটি গিট কমিট হুক দ্বারা সমাধান করা উচিত যা পাসওয়ার্ডের মতো দেখতে (যেমন, গিটলিকস ) দেখতে পাওয়া জিনিসগুলি পরীক্ষা করে । আমি চাই লিনাস গিট লাইব্রেরির সোর্স কোডে এমন একটি সরঞ্জাম তৈরি করেছিলেন তবে হায় আফসোস, এটি হয়নি। (এটি বলাই বাহুল্য, গোপন ফাইলগুলি সর্বদা যুক্ত করা উচিত .gitignore, তবে কেউ যদি এটি করতে ভুলে যায় তবে আপনার একটি হুক দরকার)

পরেরটি একটি বিশ্বব্যাপী সংস্থা সিক্রেটস ফাইল থাকার মাধ্যমে সমাধান করা যেতে পারে, যা আদর্শভাবে কেবল পঠনযোগ্য শেয়ার্ড ড্রাইভে সংরক্ষণ করা হয়। সুতরাং, পাইথনে, আপনার মতো কিছু থাকতে পারে from company_secrets import *।

আরও গুরুত্বপূর্ণ, অন্যদের দ্বারা চিহ্নিত হিসাবে, এটি পরিবেশের ভেরিয়েবলগুলিতে সঞ্চিত গোপনীয়াগুলি হ্যাক করা সহজ। উদাহরণস্বরূপ, পাইথনে, একটি লাইব্রেরির লেখক সন্নিবেশ করতে পারে send_email(address="[e-mail]", text=json.dumps(os.environ))এবং আপনি এই কোডটি সম্পাদন করেন তবে আপনার টোস্ট হয়। আপনার সিস্টেমে কল করা ফাইল থাকলে হ্যাকিং অনেক বেশি চ্যালেঞ্জিং ~/secret_company_stuff/.my_very_secret_company_stuff।

জাঙ্গো কেবলমাত্র ব্যবহারকারী:
জ্যাঙ্গো (ডিইবিইউজি মোডে) যদি কোনও ব্যতিক্রম (ডিইবিইউজি মোডে) থাকে তবে ব্রাউজারে একটি পরিবেশের পরিবর্তনশীলের কাঁচা মান দেখায়। এটি অত্যন্ত সুরক্ষিত বলে মনে হয় যদি উদাহরণস্বরূপ, কোনও বিকাশকারী ঘটনাক্রমে DEBUG=Trueউত্পাদনে সেট করে। এর বিপরীতে, জ্যাঙ্গো স্ট্রিং খুঁজছেন দ্বারা অস্পষ্ট পাসওয়ার্ড সেটিংস ভেরিয়েবল শুরু করে API, TOKEN, KEY, SECRET, PASSবা SIGNATUREফ্রেমওয়ার্ক এর settings.pyফাইলের পরিবর্তনশীল নাম থাকবে না।