সেরা অভ্যাসগুলি: সল্টিং এবং পেপারিং পাসওয়ার্ডগুলি?


145

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

hash_function($salt.hash_function($pepper.$password)) [multiple iterations]

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

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

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

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

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


3
না বেশ সদৃশ কিন্তু অত্যন্ত সম্পর্কিত: stackoverflow.com/questions/16594613/...
ircmaxell

উত্তর:


307

ঠিক আছে. দেখতে দেখতে যেমন আমি এই সম্পর্কে লিখতে প্রয়োজন উপর এবং উপর , আমি একা মরিচ উপর এক শেষ ক্যানোনিকাল উত্তর চেষ্টা করবো।

গোলমরিচ এর আপ্সাইড

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

তাই অনেক লোক বিশ্বাস করে যে মরিচগুলি একটি ভাল ধারণা। এটি "জ্ঞান করে তোলে"।

গোলমরিচ এর বাস্তবতা

সুরক্ষা এবং ক্রিপ্টোগ্রাফি রাজ্যে, "জ্ঞান তৈরি করুন" যথেষ্ট নয়। এটিকে সুরক্ষিত হিসাবে বিবেচনা করার জন্য কোনও কিছু প্রমাণযোগ্য এবং বোধগম্য হতে হবে। অতিরিক্তভাবে, এটি একটি রক্ষণাবেক্ষণযোগ্য উপায়ে কার্যকর করতে হবে। সর্বাধিক সুরক্ষিত ব্যবস্থা যা রক্ষণাবেক্ষণ করা যায় না সেটিকে অনিরাপদ হিসাবে বিবেচনা করা হয় (কারণ যদি সেই সুরক্ষাটির কোনও অংশ ভেঙে যায় তবে পুরো সিস্টেমটি পৃথক হয়ে যায়)।

এবং মরিচগুলি প্রবণতাযোগ্য বা রক্ষণাবেক্ষণযোগ্য মডেলগুলির সাথেও ফিট করে না ...

মরিচগুলির সাথে তাত্ত্বিক সমস্যা

এখন যেহেতু আমরা মঞ্চটি নির্ধারণ করেছি, আসুন মরিচগুলির মধ্যে কী কী আছে তা দেখুন।

  • অন্য একটি হ্যাশ খাওয়ানো বিপজ্জনক হতে পারে।

    আপনার উদাহরণে, আপনি কি hash_function($salt . hash_function($pepper . $password))

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

    এটা কেন মত আলগোরিদিম এর PBKDF2 বিশেষ অপারেশন ব্যবহার তাদের (যে ক্ষেত্রে hmac) একত্রিত করতে হবে।

    মুল বক্তব্যটি হ'ল এটি কোনও বড় বিষয় নয়, কেবল চারপাশে ছুঁড়ে ফেলাও তুচ্ছ বিষয় নয়। ক্রিপ্টো সিস্টেমগুলি "কাজ করা উচিত" কেসগুলি এড়ানোর জন্য ডিজাইন করা হয়েছে এবং পরিবর্তে "কাজ করার জন্য নকশাকৃত" ক্ষেত্রে ফোকাস করে।

    যদিও এটি খাঁটি তাত্ত্বিক মনে হতে পারে, বাস্তবে তা নয়। উদাহরণস্বরূপ, Bcrypt যথেচ্ছ পাসওয়ার্ড গ্রহণ করতে পারে না । সুতরাং পাস করার bcrypt(hash(pw), salt)ফলে সত্যিকারের চেয়ে দূরের দুর্বল হ্যাশ হতে পারে bcrypt(pw, salt)যদি hash()বাইনারি স্ট্রিং দেয় returns

  • ডিজাইনের বিপরীতে কাজ করা

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

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

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

    সুতরাং যতক্ষণ না গোপনীয় মান (মরিচ) ব্যবহারের জন্য ক্রিপ্টোগ্রাফারদের দ্বারা অ্যালগরিদমগুলি ডিজাইন করা এবং পরীক্ষিত না করা হয় ততক্ষণ বর্তমান অ্যালগরিদমগুলি সেগুলি ব্যবহার করা উচিত নয়।

  • জটিলতা সুরক্ষার শত্রু

    বিশ্বাস করুন বা না করুন, জটিলতা হ'ল নিরাপত্তার শত্রু । জটিল দেখায় এমন একটি অ্যালগরিদম তৈরি করা নিরাপদ হতে পারে, বা এটি নাও হতে পারে। তবে সম্ভাবনাগুলি যথেষ্ট তাৎপর্যপূর্ণ যে এটি নিরাপদ নয়।

মরিচগুলির সাথে উল্লেখযোগ্য সমস্যা

  • এটি রক্ষণাবেক্ষণযোগ্য নয়

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

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

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

    যা মূলত আপনার পদ্ধতির তাত্ক্ষণিকভাবে অস্থির করে তোলে।

  • এটি আপনার নিজের ক্রিপ্টো রোল করা প্রয়োজন ires

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

    যে কোনও ব্যক্তি, সবচেয়ে ক্লাসহীন অপেশাদার থেকে সেরা ক্রিপ্টোগ্রাফার পর্যন্ত, একটি অ্যালগরিদম তৈরি করতে পারে যা সে নিজেই ভেঙে দিতে পারে না।

    আপনার নিজের ক্রিপ্টো কখনও রোল করবেন না ...

ভাল উপায়

সুতরাং, উপরে বর্ণিত সমস্ত সমস্যার মধ্যে পরিস্থিতি সামাল দেওয়ার দুটি উপায় রয়েছে।

  • অ্যালগোরিদমগুলি যেমন রয়েছে তেমন ব্যবহার করুন

    আপনি যদি bcrypt বা সঠিকভাবে স্ক্রিপ্ট ব্যবহার করেন (উচ্চ মূল্যের সাথে), তবে সবচেয়ে দুর্বল অভিধানের পাসওয়ার্ডগুলি পরিসংখ্যানগত দিক থেকে নিরাপদ হওয়া উচিত। 5 ব্যয়ে হ্যাশিং বিক্রিপ্টের বর্তমান রেকর্ডটি প্রতি সেকেন্ডে 71k হ্যাশ। এই হারে এমনকি একটি 6 টি অক্ষরের এলোমেলো পাসওয়ার্ড ক্র্যাক হতে কয়েক বছর সময় নেয়। এবং আমার সর্বনিম্ন প্রস্তাবিত ব্যয় বিবেচনা 10, যা 32 এর গুণক দ্বারা প্রতি সেকেন্ডে হ্যাশগুলি হ্রাস করে So সুতরাং আমরা প্রতি সেকেন্ডে প্রায় 2200 হ্যাশ সম্পর্কে কথা বলব। এই হারে, এমনকি কিছু অভিধান বাক্যাংশ বা মোডেফিটনগুলি নিরাপদ থাকতে পারে।

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

  • সংগ্রহস্থলের আগে আউটপুট হ্যাশ এনক্রিপ্ট করুন

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

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

টি এল / ডিআর

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


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

2
@ মার্টিনস্টোকেলি: আমি সরলিকৃত হ্যাশিং এপিআইতে এনক্রিপশন পদক্ষেপ যুক্ত করতে সম্মত হই না। কারণটি হ'ল গোপনীয়তা (কীগুলি) সঞ্চয় করা লোকেরা যেভাবে বুঝতে পারে তার থেকে অনেক বেশি শক্ত এবং নিজেকে পায়ে গুলি করা বেশ সহজ। সেখানকার 99.9% ব্যবহারকারীর জন্য কাঁচা
ব্রক্রিপট

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

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

স্টোরেজ করার আগে আউটপুটটির এনক্রিপশন সম্পর্কিত আমার একটি প্রশ্ন রয়েছে। যদি আমি ভুল না হয়ে থাকি তবে এনক্রিপশন কীগুলি সাধারণত বার্তাগুলিকে স্বতন্ত্র বা অস্থায়ীভাবে এনক্রিপ্ট করতে ব্যবহৃত হয়। তবে আপনার কাছে যদি 200,000 ব্যবহারকারীর পাসওয়ার্ডগুলি একই কী দিয়ে এনক্রিপ্ট করা এবং একসাথে সঞ্চিত থাকে, তবে কীটি কীটিকে আক্রমণ করা সহজ করে না? মাত্র 1 বা 2 এর তুলনায় আপনার কাছে এখন 200,000 বার্তা রয়েছে
AgmLauncher 15'15

24

প্রথমে আমাদের একটি মরিচের সঠিক সুবিধা সম্পর্কে কথা বলা উচিত :

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

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

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

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

দ্বিতীয় প্রশ্নটি মরিচটি কীভাবে প্রয়োগ করবেন ?

একটি মরিচ প্রয়োগ করার প্রায়শই প্রস্তাবিত উপায় হ্যাশ ফাংশনে যাওয়ার আগে পাসওয়ার্ড এবং গোলমরিচ একত্রিত করা:

$pepperedPassword = hash_hmac('sha512', $password, $pepper);
$passwordHash = bcrypt($pepperedPassword);

আরও একটি ভাল উপায় আছে যদিও:

$passwordHash = bcrypt($password);
$encryptedHash = encrypt($passwordHash, $serverSideKey);

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


সুতরাং আপনি কি বলতে চান একটি মরিচ সংক্ষেপে কেবল একটি লবণের উপরে সুরক্ষা যুক্ত করে? কীভাবে বাস্তবায়ন করতে সাহায্যের জন্য ধন্যবাদ।
গ্লাচ ডিজায়ার

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

এটি কার্যকর করার জন্য @ মার্টিনস্টোকেলি অবশ্যই একটি ভাল উপায়। কিছু সুরক্ষার অভিজ্ঞতার সাথে কেউ এই পদ্ধতিটিকে সমর্থন করে তা দেখে ভাল। কোনও মাইএসকিউএল কলও কি AES_ENCRYPT($passwordHash, $serverSideKey)এটি কার্যকর করার উপযুক্ত উপায় হতে পারে?
ফুচো

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

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

2

লবণ এবং গোলমরিচ এর বিন্দুটি হ'ল একটি প্রাক-গণিত পাসওয়ার্ড অনুসন্ধানের ব্যয় বৃদ্ধি করা, যাকে বলা হয় রংধনু টেবিল।

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

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

তবে লবণের বিষয়টি হ'ল প্রতিটি ব্যবহারকারীর জন্য রংধনু টেবিলটি ব্যবহারকারীর কাছে অনন্য হয়ে ওঠা এবং আক্রমণটির জটিলতা আরও বাড়িয়ে তোলা।

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


সুতরাং একটি লবণ + গোলমরিচ কেবল একটি লবণের চেয়ে আরও সুরক্ষা দেয়? অথবা আমি মরিচটি ফেলে ফেলা এবং স্ক্রিপ্টের আরও পুনরাবৃত্তিগুলি চালানো থেকে আরও ভাল হতে পারি?
গ্লাচ ডিজায়ার

2
রংধনু টেবিলের প্রধান বিষয় হ'ল আপনি কোনও নির্দিষ্ট আক্রমণে একটি তৈরি করেন না, আপনি একটি পূর্ব-বিদ্যমান ডাউনলোড করেন download জনপ্রিয় হ্যাশ অ্যালগরিদমগুলির জন্য মাত্র একটি গুগল দূরে লম্বা রেইনবো টেবিল রয়েছে!
রিচার্ড

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

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

1

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

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


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

3
এটি হ্যাশকে ডেটাবেসে পাওয়া যায় না এমন তথ্যের ভিত্তিতে শক্তিশালী করে, যা একটি ভাল জিনিস thing ডাটাবেসটিতে থাকা জিনিসগুলি দুর্বলতায় প্রকাশিত হতে পারে - কোডের কোনও মান একইভাবে অ্যাক্সেস হওয়ার সম্ভাবনা কম।
রিচার্ড

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

1
@ লাইটিংডাস্ট আমি মনে করি আপনার অর্থ "হ্যাশগুলি ট্র্যাপডোর ফাংশন"। হ্যাঁ সুরক্ষিত হ্যাশ থেকে আপনার লবণ এবং / বা মরিচ বের করা অসম্ভব (বাস্তবে এটি একটি সুরক্ষিত হ্যাশের সংজ্ঞা)।
আরন

6
অস্পষ্টতার মাধ্যমে অ্যারন সুরক্ষা @ প্রতিরক্ষা স্তর হিসাবে ব্যবহৃত একটি বৈধ কৌশল হতে পারে। মুল বক্তব্যটি হ'ল এটির প্রতিরক্ষা হিসাবে কখনও নির্ভর করা উচিত নয় , পরিবর্তে "আক্রমণকারীকে ধীর করতে" ব্যবহৃত হত। যদি এটি না হয়, হানিপোটের মতো কিছু ব্যবহার করা হত না। পরিবর্তে, আমরা যতক্ষণ না আমাদের অ্যাপ্লিকেশনটির সুরক্ষার জন্য এটির উপর নির্ভর না করি ততক্ষণ আমরা ধীর আক্রমণকারীদের নিচে সহায়তা করতে অস্পষ্টতার মাধ্যমে সুরক্ষা কার্যকরভাবে ব্যবহার করতে পারি।
ইরকম্যাকেল
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.