জনসাধারণের মুখোমুখি ডাটাবেস আইডিকে কী অস্পষ্ট / অস্পষ্ট করে রাখা সত্যিই একটি "সেরা অনুশীলন"?


23

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

সম্পাদনা : অবশ্যই, এখন যেহেতু আমি এটি জিজ্ঞাসা করছি, আমি এই বিষয়ে কিছু সংস্থান খুঁজে পেয়েছি:

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


আমি অস্পষ্টতা এবং সুরক্ষার মধ্যে পার্থক্যগুলি বুঝতে পারি, পাশাপাশি কীভাবে দুজন একসাথে কাজ করতে পারে তবে কেন এটি প্রয়োজনীয় হবে তা আমি ভাবতে পারি না।

এটির কি সত্যতা আছে, এটি কি কেবল প্যারানাইয়া, বা এটি পুরোপুরি পুরোপুরি জাল?

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

এটি কি সত্যিই একটি "সেরা অনুশীলন" হিসাবে বিবেচনা করা হয় বা এটি কেবলমাত্র অল্প মূল্যটির একটি মাইক্রো-অপ্টিমাইজেশন?

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

উত্তর:


28

আমি এটা যে গুরুত্বপূর্ণ মনে করি না, কিন্তু কিছু পরিস্থিতিতে যখন এটি হয় পারে অন্যান্য সিদ্ধান্ত আপনার করা উপর নির্ভর করে ব্যাপার।

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

থিমটিতে অনুরূপ, কম পরিশীলিত, তবে বিব্রতকর বিভিন্নতা রয়েছে; যদি কোনও খারাপ লোক অর্ডার আইডিকে কোনও রশিদে ইমেল করা লিঙ্কটি বাড়িয়ে দেয় এবং লিঙ্কটিতে ক্লিক করা ব্যক্তির অর্ডার আইডি দেখার অধিকার আছে কিনা তা যাচাই করার জন্য যদি অতিরিক্ত কোনও বৈধতা না দেওয়া হয়, হঠাৎ আপনি অজান্তেই ব্যক্তিগত গ্রাহকের তথ্য প্রকাশ করছেন ভুল ব্যক্তির কাছে

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

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

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


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

9

এটি আমার নিন:

যদিও "অস্পষ্টতার মধ্য দিয়ে সুরক্ষা" স্পষ্টতই যথেষ্ট নয়, অস্পষ্টতা কিছুটা হলেও সুরক্ষাকে সহায়তা করতে পারে। আপনার সিদ্ধান্ত নিতে হবে যে এই অল্প কিছুটা সুরক্ষিত-সুরক্ষা আপনার আবেদনে এর মতো কিছু স্থাপন করতে যে অতিরিক্ত পরিশ্রম লাগবে তা মূল্যবান কিনা।

সুরক্ষা বাহিরের আরও একটি কারণ আছে যা আমি এটি বাস্তবায়নের জন্য ভাবতে পারি:

গোপনীয়তা

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

আমি উল্লেখ করা লিঙ্কটি থেকে :

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

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


2

"অস্পষ্ট" শব্দটি সম্ভবত এখানে কিছুটা বিভ্রান্তিকর, এবং, মানুষকে "অবফসকেট" বা "আংশিকভাবে লুকিয়ে" ভাবাতে পরিচালিত করতে পারে।

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

এটি ইউআরএলটিতে থাকা সংখ্যাগুলির সাথে খেলতে এবং অন্যান্য রেকর্ডগুলিতে অ্যাক্সেস করা খুব সহজ।


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

2

আমি মূলধারার বিরুদ্ধে যাব এবং আপনাকে বলব যে এলোমেলো, দীর্ঘ শনাক্তকারী ব্যবহার করা আমার মতে সুরক্ষার একটি সুন্দর শালীন রূপ।

যার কাছে সেই ডেটাতে অ্যাক্সেস রয়েছে তার কাছে এটি অবশ্যই স্পষ্ট করে দিতে হবে যে এটি পাসওয়ার্ডের মতোই সংবেদনশীল। এবং অবশ্যই এর অসুবিধা আছে যে এটি বন্যের মধ্যে গেলে এটি পরিবর্তন করা আরও কঠিন be

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

অবশ্যই, সুরক্ষার যত স্তর রয়েছে তত ভাল। তবে একা এই পদ্ধতিটি বেশ কয়েকটি শংসাপত্রের চেয়ে বেশি সুরক্ষিত হতে পারে।


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

0

এর দুটি দিক রয়েছে: ব্যবহারযোগ্যতা এবং সুরক্ষা।

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

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


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

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

0

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

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

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


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

0

স্পষ্টতই এটি নির্ভর করে যে ডেটাটি কতটা সংবেদনশীল তবে মাঝারি সুরক্ষার জন্য আমি আইডি এবং একটি চেকসামের মান অন্তর্ভুক্ত করতে পারি।

আইডির আগে এবং পরে লবণ (অর্থাত্‍ এলোমেলো অক্ষরের একটি সেট সংগ্রহ) যোগ করে এবং মানটিতে MD5 করে চেকসাম তৈরি করুন।

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

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

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