বিদ্যমান ব্যবহারকারীদের জন্য একটি নতুন পাসওয়ার্ড জোর না করে পাসওয়ার্ড হ্যাশিং আপডেট করা

Question

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

ব্যবহারকারীদের জন্য একটি 'সরলবাদী' ডাটাবেস মডেল ধরে নিন:

1. আইডি
2. ইমেইল
3. পাসওয়ার্ড

কীভাবে কেউ এ জাতীয় প্রয়োজনীয়তা সমাধানে ঘুরতে যায়?

---

আমার বর্তমান চিন্তাভাবনাগুলি হ'ল:

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

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

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

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

Comments

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

— কিলিয়ান ফথ

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

— মাইকেল কোহেন

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

— গ্লেনপিটারসন

কেন শুধু পুরাতন হ্যাশ নয়?

— সিয়ুয়ান রেন

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

— মাইকেল ডুরান্ট

Answer 1

আমি একটি নতুন ক্ষেত্র যুক্ত করার পরামর্শ দিচ্ছি, "হ্যাশ_মোথডো", সম্ভবত একটি 1 পুরানো পদ্ধতিটি বোঝাতে এবং 2 টি নতুন পদ্ধতির ইঙ্গিত দেবে।

যুক্তিযুক্তভাবে বলতে গেলে, আপনি যদি এই ধরণের জিনিসটির বিষয়ে যত্নশীল হন এবং আপনার প্রয়োগ তুলনামূলকভাবে দীর্ঘকালীন হয় (যা সম্ভবত এটি ইতিমধ্যে ইতিমধ্যে রয়েছে) তবে এটি সম্ভবত আবার ঘটতে চলেছে কারণ ক্রিপ্টোগ্রাফি এবং তথ্য সুরক্ষা যেমন একটি বিকশিত, বরং প্রত্যাশিত ক্ষেত্র। একটা সময় ছিল যখন MD5 এর মাধ্যমে একটি সাধারণ রান স্ট্যান্ডার্ড ছিল, যদি হ্যাশিং ব্যবহার করা হত আদৌ! তারপরে কেউ ভাবেন যে তাদের SHA1 ব্যবহার করা উচিত, এবং এখন সেখানে সল্টিং, বৈশ্বিক লবণ + স্বতন্ত্র এলোমেলো লবণ, এসএএএ 3, ক্রাইপ্টো-রেডি এলোমেলো সংখ্যা জেনারেশনের বিভিন্ন পদ্ধতি ... এটি কেবল 'থামাতে' যাচ্ছে না, তাই আপনি সম্ভবত এটি একটি এক্সটেনসিবল, পুনরাবৃত্তিযোগ্য উপায়ে ঠিক করুন।

সুতরাং, এখন বলতে দিন আপনার মতো কিছু রয়েছে (সরলতার জন্য সিউডো-জাভাস্ক্রিপ্টে, আমি আশা করি):

var user = getUserByID(id);
var tryPassword = hashPassword(getInputPassword());


if (user.getPasswordHash() == tryPassword)
{
    // Authenticated!
}

function hashPassword(clearPassword)
{
    // TODO: Learn what "hash" means
    return clearPassword + "H@$I-I";
}

আরও ভাল পদ্ধতি আছে তা বুঝতে পেরে আপনাকে কেবল একটি ছোটখাটো রিফ্যাক্টরিং দেওয়া দরকার:

var user = getUserByID(id);
var tryPassword = hashPassword(getInputPassword(), user.getHashingMethod());

if (user.getPasswordHash() == tryPassword)
{
    // Authenticated!
}

function hashPassword(clearPassword, hashMethod)
{
    // Note: Hash doesn't mean what we thought it did. Oops...

    var hash;
    if (hashMethod == 1)
    {
        hash = clearPassword + "H@$I-I";
    }
    else if (hashMethod == 2)
    {
        // Totally gonna get it right this time.
        hash = SuperMethodTheNSASaidWasAwesome(clearPassword);
    }
    return hash;
}

এই উত্তরটি তৈরিতে কোনও গোপন এজেন্ট বা প্রোগ্রামার ক্ষতিগ্রস্থ হয়নি।

Comments

+1 এটি বেশ বুদ্ধিমান বিমূর্ত মত মনে হচ্ছে, ধন্যবাদ। যদিও আমি এটি প্রয়োগ করি তখন আমি হ্যাশ এবং হ্যাশমেডোথ ফিল্ডগুলিকে একটি পৃথক টেবিলের দিকে নিয়ে যেতে পারি।

— উইলেম

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

— কোডসইনচাউস

পাসওয়ার্ড হ্যাশিং গত 15 বছরের মধ্যে সবেমাত্র বিকশিত হয়েছে। Bcrypt 1999 সালে প্রকাশিত হয়েছে এবং এখনও প্রস্তাবিত হ্যাশগুলির মধ্যে রয়েছে। এর পর থেকে কেবলমাত্র একটি উল্লেখযোগ্য উন্নতি ঘটেছে: ক্রমান্বয়ে মেমরি হার্ড হ্যাশগুলি, স্ক্রিপ্ট দ্বারা অগ্রণী।

— কোডসইনচাউস

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

— জানাতে হবে

Answer 2

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

ধারণাটি মূলত হ্যাশ হ্যাশ করার জন্য । pপরবর্তী লগইন করার পরে ব্যবহারকারীরা তাদের বিদ্যমান পাসওয়ার্ড ( ) সরবরাহ করার অপেক্ষা অপেক্ষা , আপনি তত্ক্ষণাত পুরানো অ্যালগরিদম ( ) দ্বারা উত্পাদিত বিদ্যমান হ্যাশটিতে নতুন হ্যাশিং অ্যালগরিদম ( H2) ব্যবহার করুন :H1

hash = H2(hash)  # where hash was previously equal to H1(p) 

এই রূপান্তরটি করার পরেও আপনি এখনও পাসওয়ার্ড যাচাই করতে পারছেন; ব্যবহারকারী যখনই পাসওয়ার্ড দিয়ে লগ ইন করার চেষ্টা করে তখন আপনাকে H2(H1(p'))আগেরটির পরিবর্তে গণনা করা দরকার ।H1(p')p'

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

hash = H2(p)

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

Comments

একটি দৈত্য +1: এইচ 2 (এইচ 1 (পি)) সাধারণত এইচ 2 (পি) সরাসরি ব্যবহারের মতোই সুরক্ষিত হয়, এমনকি এইচ 1 ভয়ঙ্কর হলেও কারণ (1) লবণ এবং প্রসারিত এইচ 2 দ্বারা যত্ন নেওয়া হয়, এবং (2) সমস্যাগুলি এমডি 5 এর মতো "ভাঙ্গা" হ্যাশ দিয়ে পাসওয়ার্ড হ্যাশিং প্রভাবিত করে না। সম্পর্কিত: crypto.stackexchange.com

— দ্য

মজার বিষয়, আমি পুরানো হ্যাশটিকে এক ধরণের সুরক্ষা 'ইস্যু' তৈরি করবে বলে মনে করেছি। মনে হচ্ছে আমার ভুল হয়েছে।

— উইলেম

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

— কোডসইনচাউস

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

— Xion

Answer 3

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

এই পরিস্থিতি এড়াতে, আপনি আপনার সক্রিয় ব্যবহারকারীদের জন্য নতুন হ্যাশিং অ্যালগরিদমে স্যুইচ করার জন্য অপেক্ষা করতে পারেন, তারপরে:

1. ব্যবহারকারীদের অ্যাকাউন্টগুলি সরান যারা খুব বেশি সময় ধরে প্রমাণীকরণ করেন নি। যে ব্যবহারকারী কখনও তিন বছরে ওয়েবসাইটে আসেনি এমন কোনও অ্যাকাউন্টের অ্যাকাউন্ট সরানোর ক্ষেত্রে কোনও ভুল নেই।

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

   সতর্কতা অবলম্বন করুন: আপনার কাছে যদি কোনও স্প্যাম বিকল্প নেই ব্যবহারকারীরা আপনার ওয়েবসাইটে চেক করতে পারেন, ব্যবহারকারীরা এটি পরীক্ষা করে তাদের ইমেল প্রেরণ করবেন না।

3. অবশেষে, পদক্ষেপ 2 এর কয়েক সপ্তাহ পরে, এখনও যারা পুরানো কৌশলটি ব্যবহার করছেন তাদের পাসওয়ার্ডটি ধ্বংস করুন। কখন এবং যদি তারা প্রমাণীকরণের চেষ্টা করে, তারা দেখতে পাবে যে তাদের পাসওয়ার্ডটি অবৈধ; যদি তারা এখনও আপনার পরিষেবায় আগ্রহী হয় তবে তারা এটি পুনরায় সেট করতে পারে।

Answer 4

আপনার কাছে সম্ভবত একাধিক হ্যাশ প্রকারের বেশি কখনও থাকতে হবে না, তাই আপনি আপনার ডাটাবেস না বাড়িয়ে সমাধান করতে পারেন।

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

Answer 5

আমি এর মতো কিছু করেছি এবং এটির নতুন হ্যাশ কিনা এবং এটি আরও সুরক্ষিত করে তোলার একটি উপায় রয়েছে। আপনি যদি আপনার হ্যাশ আপডেট করার জন্য সময় নিচ্ছেন ;-) আপনার পক্ষে আরও সুরক্ষিত অনুমান করা ভাল you

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

এইভাবে, যদি আমার পাসওয়ার্ডটি "পাস 123" এবং এলোমেলো লবণের পরিমাণ 3333 হয় তবে আমার নতুন পাসওয়ার্ডটি "পাস 1233333" এর হ্যাশ হবে।

ব্যবহারকারীর কাছে যদি লবণ থাকে তবে আপনি জানেন এটি নতুন হ্যাশ। যদি ব্যবহারকারীর লবণ নাল হয় তবে আপনি জানেন এটি পুরানো হ্যাশ।

Answer 6

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

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

Comments

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

— সান বার্টন