একটি ডাটাবেসে একটি ব্রাইপেট হ্যাশ পাসওয়ার্ড সংরক্ষণ করার জন্য আমার কলামের ধরণ / দৈর্ঘ্যটি ব্যবহার করা উচিত?


317

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

সম্পাদনা

উদাহরণ হ্যাশ:

$2a$10$KssILxWNR6k62B7yiX0GAe2Q7wwHlrzhF3LqtVvpyvHZf0MwvNfVu

কিছু পাসওয়ার্ড হ্যাশ করার পরে, মনে হয় বিসিক্রিপ সর্বদা 60 টি অক্ষরের হ্যাশ তৈরি করে।

সম্পাদনা 2

বাস্তবায়নের উল্লেখ না করার জন্য দুঃখিত। আমি জেবিসিক্রিপ্ট ব্যবহার করছি


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

1
যদি কেউ এটিকে স্ক্রিপ্টের সমাধান খুঁজছেন : গাম্বোর উত্তরটি স্ক্রিপ্টের ক্ষেত্রেও প্রযোজ্য। আমি ব্যক্তিগতভাবে মাইএসকিউএল-এ BINARY (applied৪) প্রয়োগ করেছি এবং এটি পরে পাইথনের অধীনে বাইট সমতার জন্য আমাকে পরীক্ষা করার অনুমতি দেয়।
ফিলিপ হেবার্ট

উত্তর:


368

বিসিক্রিপ্টের জন্য মডিউলার ক্রিপ্ট ফর্ম্যাটটি রয়েছে

  • $2$, $2a$বা হ্যাশিং অ্যালগরিদম এবং ফর্ম্যাট$2y$ সনাক্তকরণ
  • ব্যয়ের পরামিতিটি বোঝায় একটি দুটি অঙ্কের মান, তারপরে $
  • একটি 53 অক্ষরের বেস-64-এনকোড করা মানকে (তারা বর্ণমালা ব্যবহার ., /, 0- 9, A- Z, a- zযে ভিন্ন মান বেস 64 এনকোডিং বর্ণমালা) গঠিত:
    • লবণের 22 টি অক্ষর (কার্যকরভাবে কেবল 132 ডিকোডড বিটের 128 বিট)
    • এনক্রিপ্ট আউটপুট এর 31 টি অক্ষর (কার্যকরভাবে 186 ডিকোড বিটগুলির মধ্যে কেবল 184 বিট)

সুতরাং মোট দৈর্ঘ্য যথাক্রমে 59 বা 60 বাইট।

আপনি যেমন 2a ফর্ম্যাটটি ব্যবহার করেন, আপনার 60 বাইট লাগবে। এবং মাইএসকিউএল জন্য এইভাবে আমি ব্যবহার সুপারিশ করব CHAR(60) BINARYবাBINARY(60) (দেখুন _bin এবং বাইনারি Collations পার্থক্য সম্পর্কে তথ্যের জন্য)।

CHARবাইনারি নিরাপদ নয় এবং সাম্যতা কেবলমাত্র বাইট মানের উপর নির্ভর করে না তবে আসল কোলেশনের উপর নির্ভর করে; সবচেয়ে খারাপ ক্ষেত্রে Aসমান হিসাবে বিবেচিত হয় a। দেখুন এবং Collations আরও তথ্যের জন্য।_binbinary


28
সচেতন থাকুন - বাইনারি হিসাবে সংরক্ষণ (60) স্ট্রিং সমতা (অন্যান্য জিনিসের মধ্যে) জন্য অপ্রত্যাশিত আচরণের কারণ হতে পারে। নেট এ স্ট্রিং.এক্কুলস (ডেটাবেসাইনারি 60 স্ট্রিং, টিপিকালিশ স্ট্রিং, স্ট্রিংকম্পারেশন.আইভারিয়ান্টক্ল্যাচার) ব্যবহার করে কাটিয়ে উঠতে পারেন
জেহাববার্ড

8
আপনি যদি কলামটিকে ()০) চরিত্র সেট হিসাবে ল্যাটিন 1 কল্টেট ল্যাটিন 1_bin হিসাবে সংজ্ঞায়িত করেন তবে আপনি এখন বাইনারি কলামের প্রয়োজন ছাড়াই সঠিক স্ট্রিং তুলনার সুবিধা পাবেন।
বেন

2
নিবন্ধটি SQL_Latin1_General_CP1_CS_ASMySQL- এ অ্যান্ড্রিফিগুইরেডো অজানা। যা জানা যায় তা হ'ল latin1_general_cs
গম্বো

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

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

51

একটি Bcrypt হ্যাশ একটি BINARY(40)কলামে সংরক্ষণ করা যেতে পারে ।

BINARY(60)অন্যান্য উত্তরগুলির হিসাবে, সবচেয়ে সহজ এবং সবচেয়ে প্রাকৃতিক পছন্দ, তবে আপনি যদি স্টোরেজ দক্ষতা সর্বাধিক করতে চান তবে আপনি হ্যাশটিকে নিরবচ্ছিন্নভাবে ডিকনস্ট্রাক্ট করে 20 বাইট সংরক্ষণ করতে পারবেন। আমি এটি আরও গভীরভাবে গিটিহাবের নথিভুক্ত করেছি: https://github.com/ademarre/binary-mcf

বিক্রিপ্ট হ্যাশগুলি এমন একটি কাঠামো অনুসরণ করে যা মডিউলার ক্রিপ্ট ফর্ম্যাট (এমসিএফ) হিসাবে পরিচিত। বাইনারি এমসিএফ (বিএমসিএফ) এই পাঠ্য হ্যাশ উপস্থাপনাগুলি আরও কমপ্যাক্ট বাইনারি কাঠামোতে ডিকোড করে। বিক্রিপ্টের ক্ষেত্রে, ফলাফল বাইনারি হ্যাশ 40 বাইট।

ব্রম্ব্রিট এমসিএফ হ্যাশের চারটি উপাদান ব্যাখ্যা করার জন্য গম্বো দুর্দান্ত কাজ করেছে:

$<id>$<cost>$<salt><digest>

বিএমসিএফের ডিকোডিংটি এরকম হয়:

  1. $<id>$ 3 বিট উপস্থাপন করা যেতে পারে।
  2. <cost>$, 04-31, 5 বিট উপস্থাপন করা যেতে পারে। এগুলি 1 বাইটের জন্য একসাথে রাখুন।
  3. 22-বর্ণের লবণের 128 বিটের একটি (অ-মানক) বেস-64৪ উপস্থাপনা। বেস -৪৪ ডিকোডিং থেকে 16 বাইট পাওয়া যায়।
  4. 31-অক্ষরের হ্যাশ ডাইজেস্টটি বেস -64 ডিকোড করে 23 বাইটে হতে পারে।
  5. এটি 40 টি বাইটের জন্য একসাথে রাখুন: 1 + 16 + 23

আপনি উপরের লিঙ্কটিতে আরও পড়তে পারেন, বা আমার পিএইচপি বাস্তবায়ন পরীক্ষা করতে পারেন, গিটহাবেও।


49
লম্বা মাঠের ব্যয়: 20 বাইট এমনকি এক মিলিয়ন + রেকর্ড: 20 এমবি, একবার আপনি এক মিলিয়ন রেকর্ডে পৌঁছে যান। অত্যন্ত জটিল সুরক্ষা ও প্রকৌশল ক্ষেত্রে ভুল ক্ষেত্রের দৈর্ঘ্যকে ভুলভাবে প্রয়োগের ব্যয়: $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ $$$$$$$$$$$$$$$$$$$$$$$$$$$$ আপনি গণিত করেন।
Kzqai

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

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

11
@ কেজকাই এখানে আপনার Bcrypt লাইব্রেরির সুরক্ষা দুর্বল করার ঝুঁকি নেই। এটি একটি ডেটা এনকোডিং যা পাসওয়ার্ড চেক করার আগে স্টোরেজ থেকে পুনরুদ্ধারে পূর্বাবস্থায় ফিরে আসে। এটি "আপনার নিজের ক্রিপ্টো রোল করবেন না" অঞ্চল নয়।
আন্দ্রে ডি

1
সুন্দর ব্যাখ্যা। :) যদিও আপনার ব্যাখ্যাটি দুর্দান্ত ধারণা দিয়েছে, আমি কেবল নিরাপদ দিকে থাকতে 60০ টি চর, এমনকি ১০০ টি চর নিয়ে যেতে চাই। দুর্দান্ত বিতর্কও @ কেজকাই এবং আন্দ্রেডি
নবীন কুমার ভি

23

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

ম্যানুয়াল পৃষ্ঠা থেকে:

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

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


20

আমি মনে করি না যে কোনও ঝরঝরে কৌশল আপনি এটি সংরক্ষণ করতে পারেন যেমন আপনি MD5 হ্যাশ দিয়ে করতে পারেন।

আমি মনে করি আপনার সেরা বেট হ'ল CHAR(60)এটি সর্বদা 60০ অক্ষরের মতো দীর্ঘ হিসাবে সংরক্ষণ করা


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

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