ডিবি পাসওয়ার্ড সুরক্ষিত করা


18

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


1
নির্মল - আপনি ওয়েবসাইট থেকে ডাটাবেসের লগইন করতে পরিচয়পত্র জমা করার সম্পর্কে জিজ্ঞাসা করা করছি, এবং না কিভাবে সঠিকভাবে ওয়েবসাইটের ব্যবহারকারীদের জন্য পাসওয়ার্ড ডাটাবেসের মধ্যে সঠিক সঞ্চয় করতে?
জো

সঠিক; এটাই আমি পেয়ে যাচ্ছি
কাজি

উত্তর:


10

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

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

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

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


1
আমরাও তেমন কিছু করি। তবে, আমরা কার্যত কার্যকারিতা দ্বারা না করে ডাটাবেসের প্রতিটি ব্যবহারকারীর / প্রয়োগের জন্য একটি নতুন অ্যাকাউন্ট তৈরি করি। এটি আমাদের জন্য দুটি সমস্যার সমাধান করে - ১) আমরা OEM এর মতো সরঞ্জামগুলিতে ডাটাবেসের ব্যবহারের পার্থক্য করতে পারি (উদাহরণস্বরূপ, আমরা দেখতে পারি যে গ্রাণুলিটি দিয়ে ডেটাবেস কে হ্যামার করছে) এবং ২) প্রতিটি ব্যবহারকারী যা দেখেন এবং এর মধ্যে অ্যাক্সেস রাখেন তা আমরা স্বতন্ত্রভাবে উপস্থাপন করতে পারি তথ্যশালা.
স্কটচের

7

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


4

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

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


3

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

এনক্রিপ্ট করা সংযোগ স্ট্রিংগুলির বাইরে এলডিএপি / কার্বেরোস / অ্যাক্টিভ ডিরেক্টরি ব্যবহার করা আপনার নিরাপদ বিকল্প হতে চলেছে।


3

যদি আপনার পাসওয়ার্ডগুলি সরল-পাঠ্যে সংরক্ষণ করা হয় তবে হ্যাশগুলি (MD5, SHA), লুক ব্যবহার করুন!


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

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

2

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

আপনি যদি সি ++ বা এর মতো চলমান থাকেন তবে আমি আপনাকে একটি সল্ট এনক্রিপ্ট / ডিক্রিপ্ট ফাংশন তৈরি করার / সন্ধান করার অনুরোধ করব এবং এর মাধ্যমে শংসাপত্রগুলি চালিত করুন এবং ফলস্বরূপ হ্যাশটিকে একটি ফাইল হিসাবে সংরক্ষণ করুন।

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


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