পাসওয়ার্ডগুলি নিরাপদ ডাটাবেসে সংরক্ষণ করা থাকলে কেন এনক্রিপ্ট করা উচিত?


78

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

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

আমি যে দৃশ্যের কথা ভাবতে পারি তা হ্যাক are আপনি কয়েক ঘন্টা আগে একটি ডাটাবেস পুনরুদ্ধার করুন এবং সবকিছু ঠিক আছে। তবে, যদি আপনার পাসওয়ার্ডগুলি সরলপাঠ্য হয় ... চোরের সমস্ত পাসওয়ার্ড রয়েছে এবং আপনাকে সেগুলি পুনরায় সেট করতে হবে। আপনার ব্যবহারকারীদের ঝামেলা।

যদি পাসওয়ার্ডগুলি এনক্রিপ্ট করা থাকে তবে আপনি কেবল পূর্ববর্তী ডাটাবেসে পুনরুদ্ধার করতে পারেন। এটা কি সঠিক চিন্তাভাবনা?


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

67
@ সান্তা পাসওয়ার্ড হ্যাশিং যথেষ্ট নয়। রেসিপিটি যথেষ্ট ভাল করতে আপনাকে কিছু লবণ যোগ করতে হবে ...
বাকুরিউ

16
দয়া করে এই সম্পর্কিত সুরক্ষাটি দেখুন: স্ট্যাক এক্সচেঞ্জ
আদি

10
বিতর্কিত ডিবিএ বলে ... ব্যবহারকারী থেকে * নির্বাচন করুন, এবং তারপরে সেই তালিকাটি গুরুতর বেতনের জন্য বিক্রয় করুন। কিছুই কখনও নিরাপদ হয় না।
জন রায়নোর

উত্তর:


194

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

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

আপনি যদি আপনার ডাটাবেস পুনরুদ্ধার করেন তবে হ্যাকারটির এখনও আপনার ব্যবহারকারীর অ্যাকাউন্টে অ্যাক্সেস রয়েছে।

আর কে জানে? তারা যদি গুগলে একই পাসওয়ার্ড ব্যবহার করে? নাকি পেপাল? যদি কোনও হ্যাকার তাদের মায়ের প্রথম নামটি বা তাদের ক্রেডিট কার্ডের শেষ 4 অঙ্কগুলিতে অ্যাক্সেস দেয়?

যদি সেগুলি অন্য অ্যাকাউন্টগুলিতে যায় তবে কী হবে? কোনও ব্যবহারকারী সহায়তা সিস্টেমের মাধ্যমে যেতে এবং আরও তথ্য পাওয়ার জন্য এটি কোনও হ্যাকারের কাছাকাছি রাখবেন না ।

শুধু ... না। এটি আপনার ব্যবহারকারীর ব্যক্তিগত তথ্য এবং এটি দেখার পক্ষে আপনার প্রয়োজন হবে না। এটিও আপনার খ্যাতি। এটি এনক্রিপ্ট করুন।

সম্পাদনা: প্রতিটি উত্তর এবং মন্তব্য পড়া থেকে ভবিষ্যতের যে কোনও পাঠককে বাঁচাতে একটি অতিরিক্ত মন্তব্য, ...

আপনি যদি এনক্রিপ্ট করতে চলেছেন (কঠোর অর্থে) তবে আপনার একটি সরকারী / বেসরকারী কী জুটি ব্যবহার করা দরকার , যা ভাল তবে আপনার এবং আপনার উভয় ব্যবহারকারীর জন্যই জীবনকে আরও কিছুটা কঠিন করে তোলে।

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


89
বা আরও ভাল, এটি হ্যাশ!
ব্লগারবার্ড

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

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

7
আপনার পাসওয়ার্ডগুলি যদি আপনার সিস্টেমে কোনও মূল্য না দেয় তবে কেন আপনাকে কখনই এনক্রিপ্ট করতে হবে? তুলনা ছাড়া অন্য কোন সময় আপনাকে পাসওয়ার্ডগুলি ডিক্রিপ্ট করতে হবে? @ পিডিআর, আপনি ওপিকে এনক্রিপ্ট করতে বলছেন না, আপনি তাকে লবণ এবং হ্যাশ বলছেন।
NobleUplift

4
আপনি তাদের পাসওয়ার্ড পুনরুদ্ধারের প্রশ্নের উত্তরগুলি হ্যাশ করতে চান। অন্যথায় এগুলি অন্য পাসওয়ার্ডের মতো অন্যান্য সাইটে intoোকার জন্য ব্যবহার করা যেতে পারে।
ঝ্যান লিংস

64

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

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

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

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

এছাড়াও, এলিন যেমন বলেছিলেন, নিজের হ্যাশিং (বা এনক্রিপশন) ব্যবহার করে চেষ্টা করবেন না। একটি স্ট্যান্ডার্ড লাইব্রেরি ব্যবহার করুন।



13
অসন্তুষ্ট কর্মীদের উল্লেখের জন্য +1 আপনি যখন একজন লোকের দোকান বা একটি ছোট সংস্থার হয়ে থাকেন তখন এটিকে উপেক্ষা করা সহজ তবে অবশেষে আপনার এমন লোকেরা কাজ করবে যাতে আপনি ব্যক্তিগতভাবে যা পরীক্ষা করেন নি।

2
ব্যবহারকারীদের একটি তালিকার মাধ্যমে লুপ করতে ফোরচ লিখে এবং তার পাসওয়ার্ডগুলি হ্যাশ করা কয়েক মিনিটের কাজ এবং সত্যিই 4000 এর পক্ষে খুব কমই কাজ হয়। php.net/manual/en/function.hash.php
এলিন

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

1
এছাড়াও @ পিপিএমসাইক্লগুই, সল্টিং এবং হ্যাশ অ্যালগরিদম সম্পর্কিত পরামর্শের জন্য আমার উত্তরটি পড়ুন ।
NobleUplift

36

কেউ আমার ডাটাবেসে, অর্থাৎ ডেটা মুছে ফেললে আমার অন্যান্য সমস্যা রয়েছে।

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

দেখুন, যদিও বিভিন্ন সিস্টেমে লোকদের বিভিন্ন পাসওয়ার্ড ব্যবহার করা উচিত , বাস্তবতা তা নয়

... এবং যেহেতু পাসওয়ার্ডগুলি হ্যাশ করা এত সহজ, তাই আপনার কাছে শিল্পের সেরা অনুশীলনগুলি অনুসরণ না করার কোনও অজুহাত নেই।


9
আমি যা বিশ্বাস করি তা আপনি সবচেয়ে গুরুত্বপূর্ণ পয়েন্ট হিসাবে তৈরি করেন: আপনার এবং আপনার কর্মীদের ব্যবহারকারীর পাসওয়ার্ডের অ্যাক্সেস থাকা উচিত নয়। হ্যাকার সম্পর্কে কে পাত্তা দেয়, ব্যবহারকারীরা যে ডেটা ধারণ করে তা হ'ল
অ্যাডাম ডেভিস

1
বিকাশকারী / প্রশাসক হিসাবে আপনার ব্যবহারকারীর পাসওয়ার্ডগুলিতে আপনার অ্যাক্সেস থাকা উচিত নয় এই বিষয়টির জন্য +1। এটি নিজেই যথেষ্ট কারণ।
ম্যাট

21

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

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

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


18

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

সংজ্ঞাগুলি একবার দেখুন:

ক্রিপ্টোগ্রাফিতে এনক্রিপশন হ'ল এনকোডিং বার্তাগুলি (বা তথ্য) এমনভাবে হয় যাতে কেবল অনুমোদিত পক্ষগুলি এটি পড়তে পারে।

এবং হ্যাশিং:

একটি হ্যাশ ফাংশন এমন কোনও অ্যালগোরিদম যা নির্বিচার দৈর্ঘ্যের ডেটা একটি নির্দিষ্ট দৈর্ঘ্যের ডেটাতে মানচিত্র করে।

অন্য কথায়, এনক্রিপশন একটি দ্বি-মুখী রূপান্তর এবং হ্যাশিং হ'ল একমুখী রূপান্তর, সুতরাং আপনি যদি পরে এগুলি দেখার জন্য ডিক্রিপ্ট না করেন তবে এটি এনক্রিপশন নয়।

এছাড়াও, শুধু হ্যাশ না, লবণ ! আপনি নিজের পাসওয়ার্ডগুলি হ্যাশ করার আগে এই পুরো পৃষ্ঠাটি পড়ুন।

অপারেটিং সিস্টেম এখন হ্যাশিং অ্যালগরিদমগুলির জন্য, আমি কোনও উচ্চ-প্রান্তের SHA-2 ভেরিয়েন্ট যেমন SHA-384 বা SHA-512 এর পরামর্শ দেব।

এবং রাউন্ড হ্যাশিং ব্যবহার নিশ্চিত করুন । একবার হ্যাশ করবেন না, একাধিকবার হ্যাশ করবেন।

আপনার লগইন প্রক্রিয়া আরও সুরক্ষিত করতে এই পৃষ্ঠাটি পড়ার বিষয়টি বিবেচনা করুন ।

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

অন্যান্য পয়েন্ট PDR তোলে করছে আমি ঠিক কি কি বলতে হবে: যারা যে ওয়েব সাইটের জন্য একই পাসওয়ার্ড ব্যবহার, হ্যাকার সামাজিক ইঞ্জিনিয়ারিং ব্যবহার আরও তথ্যের লাভ, ইত্যাদি ইত্যাদি


হ্যাশ প্লাস লবণের জন্য +1 । লবণ ছাড়াই হ্যাশ ক্র্যাক করা খুব সহজ।
কোড ম্যাভেরিক

3
আপনি কি জানেন যে একটি কোড রংয়ের টেবিলের অন্য পাশে @ কোডমেভারিক? সোনার পাত্র।
NobleUplift

পাসওয়ার্ড হ্যাশিংয়ের প্রসঙ্গে এমডি 5 এর দ্রুত হওয়া ছাড়া আর কোনও অজানা দুর্বলতা নেই এবং এটি এসএএএ -2-তেও প্রযোজ্য। একটি মন্থর, iterated নির্মাণ ব্যবহার করছে পর্যন্ত MD5 উপর রয়েছে SHA-2 চয়নের চেয়ে আরো গুরুত্বপূর্ণ।
কোডসইনচাউস

4
"আপনি নিজের পাসওয়ার্ডগুলি হ্যাশ করার আগে এই পুরো পৃষ্ঠাটি পড়ুন" - সেই পৃষ্ঠায় উল্লেখ করা হয়েছে যে আপনাকে রাউন্ড হ্যাশিং ব্যবহার করা উচিত নয় , তবে একটি হ্যাশিং পদ্ধতি যা বিশেষত প্রয়োজনীয় হিসাবে ধীরে ধীরে ডিজাইন করা হয়েছে যেমন পিবিকেডিএফ 2।
ঝমিনাল

2
SCrypt বা PBKDF2 ব্যবহার করুন, উভয়ই মেমরি বা সিপিইউয়ের ক্ষেত্রে পারফর্ম করার জন্য অত্যন্ত ব্যয়বহুল হিসাবে নকশাকৃত। ব্যবহারকারীর রেকর্ডে এলোমেলোভাবে উত্পাদিত লবণ ব্যবহার করুন। একাধিক রাউন্ড হ্যাশিং সম্পাদন করবেন না, যা কেবল সংঘর্ষের সমস্যার দিকে নিয়ে যায়।
tom.dietrich

14

এখানে একটি গুরুত্বপূর্ণ নীতি ঝুঁকির মধ্যে রয়েছে। কেবলমাত্র একজন ব্যক্তি যিনি কোনও ব্যবহারকারীর পাসওয়ার্ড জেনে কোনও ব্যবসায় রয়েছেন। এটি ব্যবহারকারী তাদের স্ত্রী / স্বামী নয়, তাদের ডাক্তার বা তাদের পুরোহিতও নয়।

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

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

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

আরও সাধারণ সমাধান হ'ল:

অ্যাপ্লিকেশনটিতে প্রথম কোনও পাসওয়ার্ড পাওয়া যায় এমন স্থানে, পাসওয়ার্ডটি হ্যাশ ফাংশনে আপনার অ্যাপ্লিকেশনটির এলোমেলো 'লবণের' মান সহ হ্যাশিং ফাংশনে পাস করা হয়।

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

এখানে সুরক্ষা প্রদানের মূল বিষয়গুলি হ'ল:

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

6
সাধারণভাবে এটি ব্যবহারকারীর নাম পরিবর্তে এলোমেলো লবণ ব্যবহার পছন্দ করে।
কোডসইনচওস

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

ঠিক আছে, অ্যাপ্লিকেশনটির নিজস্ব এলোমেলো লবণের মান রয়েছে বলে প্রস্তাবিত আপডেট হওয়া উত্তর answer
মাইকেল শ 17

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

এটি কোনও ওয়েব পরিষেবা নয়, তবে এসএসএইচ কী-পিয়ার প্রমাণীকরণ 'খাঁটি' সমাধানটি ব্যবহার করে, যেখানে সার্ভারটি একটি সর্বজনীন কী সঞ্চয় করে এবং ব্যবহারকারী একটি ব্যক্তিগত কী দিয়ে প্রমাণীকরণ করে।
সিপাস্ট গত

10

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

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


এনক্রিপশন এবং হ্যাশিংয়ের মধ্যে পার্থক্য জানার জন্য +1।
NobleUplift

8

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

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


2
দুর্ভাগ্যক্রমে, আমি পিএইচপি
5.3.3

4
5.3.3 থেকে 5.3.8 একটি আপগ্রেডের অনেক বেশি?
gbjbaanb

রেড হাটে আপনি কি চান্স? কারণ তারা ঠিকক্রমে bcrypt এ ব্যাকপোর্ট করেছে। যদি তা না হয় তবে ব্রিসিপটির পরিবর্তে SHA256 ব্যবহার করুন।
এলিন

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

একটি জিনিস যা আমি যুক্ত করব তা হল পিএইচপি 5.5+ এর পাসওয়ার্ড_হ্যাশ () ফাংশন সম্পর্কে ভাল জিনিসটি এটি ডিফল্টরূপে স্যালেন্টিং এবং এ জাতীয়ভাবে পরিচালনা করে। এর আগে আপনাকে এগিয়ে যেতে হবে এবং আর্কমেক্সেলের লাইব্রেরির মতো কিছু ব্যবহার করা দরকার যা এটি ব্যাকপোর্ট করে (তিনি 5.5 বাস্তবায়ন লিখেছিলেন)। ধরে নিবেন না যে আপনি নিজেই এলোমেলো লবণ তৈরি করতে পারেন। এটি বিশেষজ্ঞদের কাছে খুব শক্ত এবং সেরা বাম; এটি এলোমেলোভাবে পাওয়া সহজ তবে একইরকম ফলাফল যা শোষণীয় নয়।
এলিন

7

আমি পিডিআর থেকে উত্তর সঙ্গে একমত, যে উত্তরটি বর্ণিত কারণে।

আমি নিম্নলিখিতগুলি যুক্ত করব: আপনার এটি করা উচিত কারণ এটি করা সহজ এবং কোনও অ্যাপ্লিকেশনটির জন্য সর্বোত্তম অনুশীলন হিসাবে সাধারণত গৃহীত হয়। আরও সুনির্দিষ্টভাবে, কোনও ধ্রুবক স্টোরেজে লেখার আগে পাসওয়ার্ডগুলি সর্বদা নোনতা এবং হ্যাশ করা উচিত । ভাল ক্রিপ্টোগ্রাফিক হ্যাশ সল্টিং এবং বেছে নেওয়ার গুরুত্ব সম্পর্কে এখানে একটি ভাল রেফারেন্স দেওয়া আছে (এটি বেশ কয়েকটি জনপ্রিয় ভাষায় ফ্রি সোর্স কোডও সরবরাহ করে): https://crackstation.net/hashing-security.htm

অতিরিক্ত বিকাশের সময় অল্প পরিমাণে এটি আপনার ব্যবহারকারীদের যে সুরক্ষা দেয় তা এবং বিকাশকারী হিসাবে আপনার খ্যাতির পক্ষে যথেষ্ট।


সল্টিং এবং হ্যাশিং উভয়েরই উল্লেখ করার জন্য + পাশাপাশি এনক্রিপশন উল্লেখ না করার জন্য , যা এমনকি এই প্রশ্নের অন্তর্ভুক্ত নয়।
NobleUplift

2

আমি যে দৃশ্যের কথা ভাবতে পারি তা হ্যাক are

আপনার আরেকটি দৃশ্যের কথা ভাবার দরকার: ব্যবহারকারীদের পাসওয়ার্ড দেওয়ার জন্য কেউ আপনার ডিবিএ (বা অন্য কেউ আপনার ডিবিতে নির্বাচিত প্রশ্নগুলি চালাতে পারে) pped 100 কে পিছলে ফেলেছে। বা সামাজিক ইঞ্জিনিয়াররা এটি করার জন্য কিছু ইন্টার্ন রয়েছে।

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

তারপরে ইরেট ব্যবহারকারী আপনার সংস্থার পাসওয়ার্ড উন্মুক্ত করার জন্য তার বিরুদ্ধে মামলা করে।


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


2

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


1
এই কিছু যোগ্য কি ইতিমধ্যে পূর্বে উত্তর পোস্ট করা হয়েছে যোগ না
মশা

3
+1 টি। তিনি আসলে "হ্যাশিং" বলেছিলেন, অনেকের মতো এনক্রিপশনের পরিবর্তে। এছাড়াও, তিনি ওপিকে সরাসরি বিরোধিতা করেছিলেন যিনি বলেছিলেন যে তিনি পাসওয়ার্ডগুলি প্লেইনেক্সট অন্য ব্যবহারকারীদের অ্যাকাউন্টে লগইন করতে চান।
NobleUplift

0

ওয়েল, এটা বিস্ময়কর কোন এক এই উল্লিখিত হয়েছে, এখনো, কিন্তু কি সম্পর্কে শারীরিক আপনার ডাটাবেস নিরাপত্তা?

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

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

আপনার আইটি বিভাগ যখন পুরানো ড্রাইভগুলি ইন্টার্নগুলিতে "হস্তান্তর" করার আগে প্রতিস্থাপনের সময় আপনার ডিবি ধারণ করে এমন পুরানো RAID ড্রাইভগুলি মুছতে ভুলে যায় এবং তার পরে ছাত্রাবাসের রুমমেটরা পিছনে কী রেখেছিল তা খুঁজে বের করে এবং তারা বুঝতে পারে " "এটি বিক্রি করুন এবং এটি তাদের কাছে কখনও খুঁজে পাওয়া যায়নি?

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

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


-1

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


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

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

1
@RemcoGerlich কী ধারণা একটি হিসাবে পরিচিত হয় আপাতত যা প্রতিরোধ করা যাবে রিপ্লে হামলা

-1

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

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

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


2
কে অসমমিতিক এনক্রিপশন ব্যবহার করে পাসওয়ার্ড সঞ্চয় করে? এটি সর্বজনীন-কী ক্রিপ্টোগ্রাফি, যার অর্থ আমি আমার পাসওয়ার্ড এনক্রিপ্ট করার পরেও এটি ডিক্রিপ্ট করা যায় এবং যদি কেউ কখনও আমার ব্যক্তিগত কীটি পান তবে তা ডিক্রিপ্ট করা যায় এবং পড়তে পারে। হ্যাশিংয়ের সাহায্যে আমি এবং কেবলমাত্র আমি আমার পাসওয়ার্ড জানি (যদি না আমি এটি লিখে না রাখি বা পাসওয়ার্ড ম্যানেজারে না রাখি, যেখানে এটি আসলে অসমমিতিক এনক্রিপশন হয়)।
NobleUplift

দয়া করে, পাবলিক-কী ক্রিপ্টোগ্রাফির জন্য উইকিপিডিয়া পৃষ্ঠাটি দেখুন: en.wikedia.org/wiki/Public-key_cryptography "পাবলিক-কি ক্রিপ্টোগ্রাফি, যা
অসমমিতিক

2
... হ্যাঁ, আমি বললাম using asymmetric encryption? That's public-key cryptography। তোমার যুক্তি কী?
NobleUplift

-1

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

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


1
এটি 14 পূর্ববর্তী উত্তরগুলির চেয়ে বেশি কিছু দেওয়ার প্রস্তাব বলে মনে হচ্ছে না
gtat

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

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

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

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