"আমাকে লগ ইন করুন" - সর্বোত্তম পন্থা


257

আমার ওয়েব অ্যাপ্লিকেশনটি একবার লগ ইন করার পরে ব্যবহারকারী সম্পর্কে তথ্য সংরক্ষণ করার জন্য এবং অ্যাপ্লিকেশনটিতে পৃষ্ঠা থেকে অন্য পৃষ্ঠায় ভ্রমণ করার সাথে সাথে সেই তথ্য বজায় রাখতে সেশনগুলি ব্যবহার করে। এই নির্দিষ্ট আবেদন, আমি সংরক্ষণকারী করছি user_id, first_nameএবং last_nameব্যক্তির।

আমি লগ ইন করার জন্য "ক্যাপ মি লগ ইন" বিকল্পটি দিতে চাই যা ব্যবহারকারীর মেশিনে দুই সপ্তাহের জন্য একটি কুকি রাখবে, তারা অ্যাপটিতে ফিরে আসার পরে একই বিবরণ দিয়ে তাদের সেশনটি পুনরায় চালু করবে।

এটি করার জন্য সর্বোত্তম পদ্ধতির কী? আমি user_idএগুলিকে কুকিতে সংরক্ষণ করতে চাই না , কারণ মনে হচ্ছে এটির মাধ্যমে একজন ব্যবহারকারীর পক্ষে অন্য ব্যবহারকারীর পরিচয় চেষ্টা করা এবং তা জাল করা সহজ হবে।

উত্তর:


735

ঠিক আছে, আমাকে এই ভোঁতাভাবে বলতে দাও: আপনি যদি এই উদ্দেশ্যে ব্যবহারকারীর ডেটা বা ব্যবহারকারীর ডেটা থেকে প্রাপ্ত কোনও কুকির মধ্যে রাখেন তবে আপনি কিছু ভুল করছেন।

সেখানে। এটা আমি বলেছি. এখন আমরা আসল উত্তরের দিকে যেতে পারি।

হ্যাশিং ব্যবহারকারীর ডেটাতে কি সমস্যা হয়েছে, আপনি জিজ্ঞাসা করছেন? ঠিক আছে, এটি অস্পষ্টতার মাধ্যমে এক্সপোজার পৃষ্ঠ এবং সুরক্ষা নেমে আসে।

এক সেকেন্ডের জন্য কল্পনা করুন যে আপনি আক্রমণকারী। আপনি আপনার সেশনে আমাকে মনে রাখার জন্য একটি ক্রিপ্টোগ্রাফিক কুকি সেট দেখতে পান। এটি 32 অক্ষর প্রশস্ত। ঘি। এটি এমডি 5 হতে পারে ...

আসুন এক সেকেন্ডের জন্য কল্পনাও করুন যে তারা যে অ্যালগরিদমটি ব্যবহার করেছেন তা তারা জানে। উদাহরণ স্বরূপ:

md5(salt+username+ip+salt)

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

সংক্ষেপে, আপনাকে রক্ষা করার একমাত্র জিনিস হ'ল লবণ, যা সত্যই আপনাকে যতটা ভাবেন তেমন রক্ষা করে না।

কিন্তু অপেক্ষা করো!

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

ভাল উপায়

সর্বোত্তম উপায় হ'ল আইডি ব্যতীত কোনও ব্যবহারকারীর তথ্য কখনও সার্ভার ছেড়ে না দেওয়া।

যখন ব্যবহারকারী লগ ইন করে, একটি বড় (128 থেকে 256 বিট) এলোমেলো টোকেন উত্পন্ন করে। এটি একটি ডেটাবেস টেবিলটিতে যুক্ত করুন যা ইউজারিডে টোকেনটি মানচিত্র করে এবং তারপরে এটি কুকির ক্লায়েন্টকে প্রেরণ করে।

আক্রমণকারী যদি অন্য ব্যবহারকারীর এলোমেলো টোকেনটি অনুমান করে তবে কী হবে?

আচ্ছা, এখানে কিছু গণিত করা যাক। আমরা একটি 128 বিট এলোমেলো টোকেন তৈরি করছি। এর অর্থ এখানে রয়েছে:

possibilities = 2^128
possibilities = 3.4 * 10^38

এখন, এই সংখ্যাটি কতটা অযৌক্তিকভাবে বড় তা দেখানোর জন্য আসুন ইন্টারনেটে প্রতিটি সার্ভারটি কল্পনা করুন (আসুন আজ ৫০,০০,০০০ বলি) প্রতি সেকেন্ডে ১,০০,০০,০০০ হারে এই সংখ্যাটিকে জোর করে চালানোর চেষ্টা করছি। বাস্তবে আপনার সার্ভারগুলি এ জাতীয় বোঝার নীচে গলে যাবে তবে আসুন এটি খেলি।

guesses_per_second = servers * guesses
guesses_per_second = 50,000,000 * 1,000,000,000
guesses_per_second = 50,000,000,000,000,000

সুতরাং প্রতি সেকেন্ডে 50 কোয়াড্রিলিয়ান অনুমান। তাড়াতাড়ি! রাইট?

time_to_guess = possibilities / guesses_per_second
time_to_guess = 3.4e38 / 50,000,000,000,000,000
time_to_guess = 6,800,000,000,000,000,000,000

সুতরাং 6.8 সেক্সটিলিওন সেকেন্ড ...

এটিকে আরও বন্ধুত্বপূর্ণ সংখ্যায় নামানোর চেষ্টা করি।

215,626,585,489,599 years

বা আরও ভাল:

47917 times the age of the universe

হ্যাঁ, এই মহাবিশ্বের বয়স 47917 গুণ ...

মূলত, এটি ক্র্যাক হবে না।

সুতরাং সংক্ষেপে:

আমি প্রস্তাবিত আরও ভাল পদ্ধতির হ'ল কুকিটি তিনটি অংশে সঞ্চয় করা।

function onLogin($user) {
    $token = GenerateRandomToken(); // generate a token, should be 128 - 256 bit
    storeTokenForUser($user, $token);
    $cookie = $user . ':' . $token;
    $mac = hash_hmac('sha256', $cookie, SECRET_KEY);
    $cookie .= ':' . $mac;
    setcookie('rememberme', $cookie);
}

তারপরে, যাচাই করতে:

function rememberMe() {
    $cookie = isset($_COOKIE['rememberme']) ? $_COOKIE['rememberme'] : '';
    if ($cookie) {
        list ($user, $token, $mac) = explode(':', $cookie);
        if (!hash_equals(hash_hmac('sha256', $user . ':' . $token, SECRET_KEY), $mac)) {
            return false;
        }
        $usertoken = fetchTokenByUserName($user);
        if (hash_equals($usertoken, $token)) {
            logUserIn($user);
        }
    }
}

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

এখন, এটি খুব গুরুত্বপূর্ণ যে SECRET_KEYএকটি ক্রিপ্টোগ্রাফিক সিক্রেট (যেমন /dev/urandomকোনও কিছু দ্বারা উত্পন্ন এবং / অথবা উচ্চ-এনট্রপি ইনপুট থেকে প্রাপ্ত)। এছাড়াও, GenerateRandomToken()একটি শক্তিশালী র্যান্ডম উৎস হওয়া প্রয়োজন ( mt_rand()প্রায় শক্তিশালী যথেষ্ট নয়। যেমন একটি লাইব্রেরি ব্যবহার করুন RandomLib বা random_compat , অথবা mcrypt_create_iv()সঙ্গে DEV_URANDOM) ...

hash_equals()প্রতিরোধ করা হয় সময়জ্ঞান আক্রমণের । আপনি যদি পিএইচপি 5.6 এর নীচে পিএইচপি সংস্করণ ব্যবহার করেন তবে ফাংশনটি hash_equals()সমর্থিত নয়। hash_equals()এক্ষেত্রে আপনি টাইমিংসেফকম্পিয়ার ফাংশনটি প্রতিস্থাপন করতে পারেন :

/**
 * A timing safe equals comparison
 *
 * To prevent leaking length information, it is important
 * that user input is always used as the second parameter.
 *
 * @param string $safe The internal (safe) value to be checked
 * @param string $user The user submitted (unsafe) value
 *
 * @return boolean True if the two strings are identical.
 */
function timingSafeCompare($safe, $user) {
    if (function_exists('hash_equals')) {
        return hash_equals($safe, $user); // PHP 5.6
    }
    // Prevent issues if string length is 0
    $safe .= chr(0);
    $user .= chr(0);

    // mbstring.func_overload can make strlen() return invalid numbers
    // when operating on raw binary strings; force an 8bit charset here:
    if (function_exists('mb_strlen')) {
        $safeLen = mb_strlen($safe, '8bit');
        $userLen = mb_strlen($user, '8bit');
    } else {
        $safeLen = strlen($safe);
        $userLen = strlen($user);
    }

    // Set the result to the difference between the lengths
    $result = $safeLen - $userLen;

    // Note that we ALWAYS iterate over the user-supplied length
    // This is to prevent leaking length information
    for ($i = 0; $i < $userLen; $i++) {
        // Using % here is a trick to prevent notices
        // It's safe, since if the lengths are different
        // $result is already non-0
        $result |= (ord($safe[$i % $safeLen]) ^ ord($user[$i]));
    }

    // They are only identical strings if $result is exactly 0...
    return $result === 0;
}

7
তবে এই পদ্ধতির অর্থ এই নয় যে কেউ এই ব্যবহারকারীর নামটি এবং কুকি নিতে এবং অন্য কোনও ডিভাইস থেকে এই ব্যবহারকারী হিসাবে লগ ইন করতে পারে?
সরল

8
lol :-), দ্রষ্টব্য যে 47917 বছর অনুমান করার সর্বোচ্চ সময়, এলোমেলো টোকেনটিও 1 ঘন্টার মধ্যে অনুমান করা যায়।
ঝড়_বস্টার

32
এটি অদ্ভুত কারণ আপনার কোডটি আপনার উত্তরের সাথে বিরোধিতা করে। আপনি বলছেন "আপনি যদি কোনও কুকিতে ব্যবহারকারীর ডেটা রাখেন [...] আপনি কিছু ভুল করছেন", তবে আপনার কোডটি ঠিক এটি করছে! কুকি থেকে ব্যবহারকারীর নামটি সরিয়ে ফেলা, কেবল টোকেনের উপর দিয়ে হ্যাশ গণনা করা ভাল (এবং সম্ভবত কুকি চুরি রোধে আইপি ঠিকানা যুক্ত করা) এবং তারপরে স্মরণে () স্মরণে fetchTokenByUserName এর পরিবর্তে fetchUsernameByToken করবেন না?
লভেন

9
পিএইচপি 5.6 থেকে হ্যাশ_এক্কালগুলি স্ট্রিং তুলনা করার সময় সময় আক্রমণ প্রতিরোধ করতে ব্যবহার করা যেতে পারে।
F21

5
@ লিভিট এটি কাউকে বৈধ টোকেন নিতে এবং এর সাথে যুক্ত ইউজারিড পরিবর্তন করতে বাধা দেয়।
একারম্যাক্সেল

93

সুরক্ষা বিজ্ঞপ্তি : ডিটারিমেটিক ডেটার এমডি 5 হ্যাশ বন্ধ করে কুকিকে বেইজ করা একটি খারাপ ধারণা; কোনও সিএসপিআরএনজি থেকে প্রাপ্ত এলোমেলো টোকেন ব্যবহার করা আরও ভাল। আরও সুরক্ষিত পদ্ধতির জন্য এই প্রশ্নের আর্কম্যাক্সেলের উত্তর দেখুন ।

সাধারণত আমি এই জাতীয় কিছু করি:

  1. ব্যবহারকারী আমাকে 'লগ ইন রাখুন' দিয়ে লগ ইন করে
  2. সেশন তৈরি করুন
  3. এমডি 5 (নামক + ব্যবহারকারীর নাম + আইপি + লবণ) সম্বলিত একটি কুকি এবং আইডি সম্বলিত কিছুযুক্ত নামে একটি কুকি তৈরি করুন id
  4. ডাটাবেসে কুকি সঞ্চয় করুন
  5. ব্যবহারকারী স্টাফ এবং পাতা করেন ----
  6. ব্যবহারকারীর প্রত্যাবর্তন, অন্য কুকির জন্য পরীক্ষা করুন, যদি এটি উপস্থিত থাকে তবে সেই ব্যবহারকারীর জন্য ডাটাবেস থেকে পুরানো হ্যাশ পান, ডাটাবেস থেকে হ্যাশের সাথে কিছু মেলে কুকির সামগ্রীগুলি পরীক্ষা করে দেখুন, যা একটি নতুন গণনা করা হ্যাশের সাথেও মিলবে (জন্য আইপি) এইভাবে: কুকিহ্যাশ == ডাটাবেস হ্যাশ == এমডি 5 (লবণের + ব্যবহারকারীর নাম + আইপি + লবণ), যদি তারা করেন তবে 2, যদি তারা না পান তবে

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

এছাড়াও আপনি এমডি 5 এর পরিবর্তে sha1 ব্যবহার করতে পারেন (বা কোনও কোনও অ্যালগোরিদম)


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

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

3
আমি নিস্তেজ হওয়ার জন্য দুঃখিত তবে দ্বিতীয় কুকির উদ্দেশ্য কী? এক্ষেত্রে আইডি কী? ব্যবহারকারী কি আমাকে লগ ইন করে রাখা বৈশিষ্ট্যটি আদৌ ব্যবহার করতে চান কিনা তা বোঝাতে এটি কি একটি সাধারণ ধরণের "সত্য / মিথ্যা" মান? যদি তা হয় তবে কুকির কিছু প্রথম স্থানে রয়েছে কিনা তা খতিয়ে দেখবেন না কেন? যদি ব্যবহারকারী তাদের লগইনটি অবিরত রাখতে না চান, তবে কিছু কিছু কুকি প্রথম স্থানে থাকবে না? অবশেষে, আপনি কি আবার গতিশীলভাবে হ্যাশ তৈরি করছেন এবং এটি সুরক্ষার অতিরিক্ত পরিমাপ হিসাবে কুকি এবং ডিবি-র বিরুদ্ধে পরীক্ষা করছেন?
itmequinn

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

4
কেন আপনি দুটি লবণ ব্যবহার করেন? এমডি 5 (লবণের + ব্যবহারকারীর নাম + আইপি + লবণ)
অ্যারন ক্রেডার

77

ভূমিকা

আপনার শিরোনাম "আমাকে লগ ইন করুন" - সর্বোত্তম পদ্ধতির আমার পক্ষে কোথা থেকে শুরু করতে হবে তা জানতে অসুবিধা বোধ করে কারণ আপনি যদি সেরা পদ্ধতির দিকে তাকান তবে আপনাকে নিম্নলিখিত বিষয়গুলি বিবেচনা করতে হবে:

  • সনাক্ত
  • নিরাপত্তা

বিস্কুট

কুকিজগুলি দুর্বল, সাধারণ ব্রাউজার কুকি-চুরি দুর্বলতা এবং ক্রস-সাইট স্ক্রিপ্টিং আক্রমণগুলির মধ্যে আমাদের অবশ্যই মেনে নিতে হবে যে কুকিজ নিরাপদ নয়। সুরক্ষা উন্নত করতে আপনাকে অবশ্যই খেয়াল করতে হবে যাতে php setcookiesঅতিরিক্ত কার্যকারিতা যেমন

বুল সেটকুকি (স্ট্রিং $ নাম [, স্ট্রিং $ মান [, ইনট $ এক্সপায়ার = 0 [, স্ট্রিং $ পাথ [, স্ট্রিং $ ডোমেন [, বুল $ সুরক্ষিত = মিথ্যা [, বুল $ httponly = মিথ্যা]]]]]])

  • সুরক্ষিত (HTTPS সংযোগ ব্যবহার করে)
  • httponly (এক্সএসএস আক্রমণ মাধ্যমে পরিচয় চুরি হ্রাস করুন)

সংজ্ঞা

  • টোকেন (এন দৈর্ঘ্যের অনাকাঙ্ক্ষিত এলোমেলো স্ট্রিং যেমন। / দেব / ইউরানডম)
  • রেফারেন্স (এন দৈর্ঘ্যের অনাকাঙ্ক্ষিত এলোমেলো স্ট্রিং যেমন। / Dev / urandom)
  • স্বাক্ষর (এইচএমএসি পদ্ধতি ব্যবহার করে একটি কীড হ্যাশ মান উত্পন্ন করুন)

সরল পদ্ধতি

একটি সহজ সমাধান হবে:

  • ব্যবহারকারী আমাকে মনে রাখুন দিয়ে লগ ইন করেছেন
  • টোকেন এবং স্বাক্ষর সহ লগইন কুকি জারি করা হয়েছে
  • কখন ফিরে আসবে, স্বাক্ষরটি চেক করা হয়
  • স্বাক্ষর যদি ঠিক থাকে .. তবে ব্যবহারকারীর নাম এবং টোকেনটি ডাটাবেসে সন্ধান করা হবে
  • বৈধ না হলে .. লগইন পৃষ্ঠায় ফিরে
  • বৈধ হলে স্বয়ংক্রিয়ভাবে লগইন করুন

উপরের কেস স্টাডি এই পৃষ্ঠায় প্রদত্ত সমস্ত উদাহরণের সংক্ষিপ্তসার জানিয়েছে তবে তাদের অসুবিধাগুলি হ'ল

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

আরও ভাল সমাধান

আরও ভাল সমাধান হতে পারে

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

উদাহরণ কোড

// Set privateKey
// This should be saved securely 
$key = 'fc4d57ed55a78de1a7b31e711866ef5a2848442349f52cd470008f6d30d47282';
$key = pack("H*", $key); // They key is used in binary form

// Am Using Memecahe as Sample Database
$db = new Memcache();
$db->addserver("127.0.0.1");

try {
    // Start Remember Me
    $rememberMe = new RememberMe($key);
    $rememberMe->setDB($db); // set example database

    // Check if remember me is present
    if ($data = $rememberMe->auth()) {
        printf("Returning User %s\n", $data['user']);

        // Limit Acces Level
        // Disable Change of password and private information etc

    } else {
        // Sample user
        $user = "baba";

        // Do normal login
        $rememberMe->remember($user);
        printf("New Account %s\n", $user);
    }
} catch (Exception $e) {
    printf("#Error  %s\n", $e->getMessage());
}

ক্লাস ব্যবহৃত

class RememberMe {
    private $key = null;
    private $db;

    function __construct($privatekey) {
        $this->key = $privatekey;
    }

    public function setDB($db) {
        $this->db = $db;
    }

    public function auth() {

        // Check if remeber me cookie is present
        if (! isset($_COOKIE["auto"]) || empty($_COOKIE["auto"])) {
            return false;
        }

        // Decode cookie value
        if (! $cookie = @json_decode($_COOKIE["auto"], true)) {
            return false;
        }

        // Check all parameters
        if (! (isset($cookie['user']) || isset($cookie['token']) || isset($cookie['signature']))) {
            return false;
        }

        $var = $cookie['user'] . $cookie['token'];

        // Check Signature
        if (! $this->verify($var, $cookie['signature'])) {
            throw new Exception("Cokies has been tampared with");
        }

        // Check Database
        $info = $this->db->get($cookie['user']);
        if (! $info) {
            return false; // User must have deleted accout
        }

        // Check User Data
        if (! $info = json_decode($info, true)) {
            throw new Exception("User Data corrupted");
        }

        // Verify Token
        if ($info['token'] !== $cookie['token']) {
            throw new Exception("System Hijacked or User use another browser");
        }

        /**
         * Important
         * To make sure the cookie is always change
         * reset the Token information
         */

        $this->remember($info['user']);
        return $info;
    }

    public function remember($user) {
        $cookie = [
                "user" => $user,
                "token" => $this->getRand(64),
                "signature" => null
        ];
        $cookie['signature'] = $this->hash($cookie['user'] . $cookie['token']);
        $encoded = json_encode($cookie);

        // Add User to database
        $this->db->set($user, $encoded);

        /**
         * Set Cookies
         * In production enviroment Use
         * setcookie("auto", $encoded, time() + $expiration, "/~root/",
         * "example.com", 1, 1);
         */
        setcookie("auto", $encoded); // Sample
    }

    public function verify($data, $hash) {
        $rand = substr($hash, 0, 4);
        return $this->hash($data, $rand) === $hash;
    }

    private function hash($value, $rand = null) {
        $rand = $rand === null ? $this->getRand(4) : $rand;
        return $rand . bin2hex(hash_hmac('sha256', $value . $rand, $this->key, true));
    }

    private function getRand($length) {
        switch (true) {
            case function_exists("mcrypt_create_iv") :
                $r = mcrypt_create_iv($length, MCRYPT_DEV_URANDOM);
                break;
            case function_exists("openssl_random_pseudo_bytes") :
                $r = openssl_random_pseudo_bytes($length);
                break;
            case is_readable('/dev/urandom') : // deceze
                $r = file_get_contents('/dev/urandom', false, null, 0, $length);
                break;
            default :
                $i = 0;
                $r = "";
                while($i ++ < $length) {
                    $r .= chr(mt_rand(0, 255));
                }
                break;
        }
        return substr(bin2hex($r), 0, $length);
    }
}

ফায়ারফক্স এবং ক্রোমে পরীক্ষা করা হচ্ছে

এখানে চিত্র বর্ণনা লিখুন

সুবিধা

  • ভাল নিরাপত্তা
  • আক্রমণকারীর জন্য সীমিত অ্যাক্সেস
  • কুকি চুরি হয়ে গেলে এটি একক অ্যাক্সেসের জন্য বৈধ
  • এর পরে যখন আসল ব্যবহারকারীর সাইটে অ্যাক্সেস পাবেন তখন আপনি স্বয়ংক্রিয়ভাবে চুরির ব্যবহারকারীকে সনাক্ত করতে এবং তাকে অবহিত করতে পারেন

অসুবিধা

  • একাধিক ব্রাউজারের মাধ্যমে অবিচ্ছিন্ন সংযোগ সমর্থন করে না (মোবাইল এবং ওয়েব)
  • কুকিটি এখনও চুরি করা যায় কারণ ব্যবহারকারী কেবলমাত্র পরবর্তী লগইনের পরে বিজ্ঞপ্তি পায়।

দ্রুত ঠিক করা

  • অবিচ্ছিন্ন সংযোগ থাকতে হবে প্রতিটি সিস্টেমের জন্য অনুমোদনের সিস্টেমের পরিচিতি
  • প্রমাণীকরণের জন্য একাধিক কুকি ব্যবহার করুন

একাধিক কুকি পদ্ধতির

যখন কোনও আক্রমণকারী কুকিজ চুরি করতে চলেছে তবে কেবলমাত্র এটি কোনও নির্দিষ্ট ওয়েবসাইট বা ডোমেনের উপরে মনোনিবেশ করবে eg example.com

কিন্তু সত্যিই আপনি (2 টি পৃথক ডোমেন থেকে একটি ব্যবহারকারী পরিচয় প্রমাণ করতে পারে example.com & fakeaddsite.com ) এবং এটি "বিজ্ঞাপন কুকি" মত বানাতে

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

কিছু লোক ভাবতে পারে আপনি কীভাবে 2 টি আলাদা কুকিজ ব্যবহার করতে পারেন? ভাল এটি সম্ভব, কল্পনা example.com = localhostএবং fakeaddsite.com = 192.168.1.120। আপনি যদি কুকিগুলি পরিদর্শন করেন তবে এটি দেখতে এটির মতো লাগবে

এখানে চিত্র বর্ণনা লিখুন

উপরের চিত্র থেকে

  • পরিদর্শন করা বর্তমান সাইটটি লোকালহোস্ট
  • এটিতে 192.168.1.120 থেকে সেট কুকিজ রয়েছে

192.168.1.120

  • কেবল সংজ্ঞায়িত গ্রহণ করে HTTP_REFERER
  • শুধুমাত্র নির্দিষ্ট থেকে সংযোগ গ্রহণ করে REMOTE_ADDR
  • কোনও জাভাস্ক্রিপ্ট নেই, কোনও সামগ্রী নেই তবে তথ্য সাইন করা এবং কুকি থেকে এটি যুক্ত বা পুনরুদ্ধার করার পরিবর্তে কিছুই নেই

সুবিধা

  • 99% শতাংশ আপনি আক্রমণকারীকে ঠকিয়েছেন
  • আক্রমণকারীর প্রথম প্রয়াসে আপনি সহজেই অ্যাকাউন্টটি লক করতে পারেন
  • অন্যান্য পদ্ধতির মতো পরবর্তী লগইনের আগেও আক্রমণ প্রতিরোধ করা যায়

অসুবিধা

  • একক লগইনের জন্য সার্ভারে একাধিক অনুরোধ

উন্নতি

  • ইফ্রামের ব্যবহার শেষ হয়েছে ajax

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

6

আমি এই প্রশ্নের একটি কোণ এখানে জিজ্ঞাসা করেছি , এবং উত্তরগুলি আপনাকে প্রয়োজনীয় সমস্ত টোকেন-ভিত্তিক টাইম-আউট কুকি লিঙ্কগুলিতে নিয়ে যাবে।

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


6

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

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

যা বলা হচ্ছে, আপনার সিস্টেমে অটো-সাইন ইন করার দুটি দুর্দান্ত উপায় রয়েছে।

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

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

যেহেতু কোনও বহিরাগত প্রমাণীকরণকারী ব্যবহারকারীর বৈধতা আছে কিনা তা পর্দার আড়ালে সার্ভারটি বলার জন্য ব্যবহৃত হয়েছিল, তাই কোনও আক্রমণকারী একটি অনন্য আইডি ব্যতীত অন্য কোনও কিছু পেতে পারে না যা এটি নিজেরাই অকেজো। আমি বিস্তারিত বর্ণনা করব:

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

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

এই পদ্ধতিটি আপনার বাহ্যিক প্রমাণীকরণকারী ব্যবহার করে আপনার সাইটে যারা সাইন ইন করে তাদের জন্য আপনার অভ্যন্তরীণ প্রমাণীকরণকারীর সাথে একত্রে ব্যবহার করা যেতে পারে এবং ব্যবহার করা উচিত।

=========

এখন, আপনার নিজস্ব প্রমাণীকরণকারী সিস্টেমের জন্য যা ব্যবহারকারীদের স্বতঃ-সাইন ইন করতে পারে, আমি এটি এটিই করি:

ডিবিতে কয়েকটি টেবিল রয়েছে:

TABLE users:
UID - auto increment, PK
username - varchar(255), unique, indexed, NOT NULL
password_hash - varchar(255), NOT NULL
...

নোট করুন যে ব্যবহারকারীর নামটি 255 অক্ষর দীর্ঘ হতে সক্ষম। আমার সিস্টেমে আমার সার্ভার প্রোগ্রামের ব্যবহারকারী নামগুলি 32 টি অক্ষরে রয়েছে তবে বহিরাগত প্রমাণীকরণকারীর কাছে তার @ ডোমেন.রকম ব্যবহারকারীর নাম থাকতে পারে ld যেটি তার চেয়ে বড় হতে পারে, তাই আমি কেবলমাত্র সর্বোচ্চ সামঞ্জস্যের জন্য কোনও ইমেল ঠিকানার সর্বোচ্চ দৈর্ঘ্য সমর্থন করি।

TABLE sessions:
session_id - varchar(?), PK
session_token - varchar(?), NOT NULL
session_data - MediumText, NOT NULL

মনে রাখবেন যে এই টেবিলটিতে কোনও ব্যবহারকারীর ক্ষেত্র নেই, কারণ লগ-ইন থাকা অবস্থায় ব্যবহারকারীর নামটি সেশন ডেটাতে থাকে এবং প্রোগ্রামটি নাল ডেটার অনুমতি দেয় না। সেশন_আইডি এবং সেশন_ টোকেনটি এলোমেলো এমডি 5 হ্যাশগুলি, শ 1/128/256 হ্যাশগুলি ব্যবহার করে তৈরি করা যেতে পারে, তাদের সাথে এলোমেলো স্ট্রিং যুক্ত ডেটটাইম স্ট্যাম্পগুলি পরে হ্যাশ করা হয় বা আপনি যা চান তা করতে পারেন, তবে আপনার আউটপুটটির এনট্রপিটি সহনীয় হিসাবে তত বেশি থাকতে হবে এমনকি মাটি থেকে নামা থেকেও বর্বর-আক্রমণ আক্রমণগুলি প্রশমিত করুন এবং আপনার সেশন শ্রেণীর দ্বারা উত্পন্ন সমস্ত হ্যাশগুলি যোগ করার চেষ্টা করার আগে সেশন সারণীতে ম্যাচের জন্য তা পরীক্ষা করা উচিত।

TABLE autologin:
UID - auto increment, PK
username - varchar(255), NOT NULL, allow duplicates
hostname - varchar(255), NOT NULL, allow duplicates
mac_address - char(23), NOT NULL, unique
token - varchar(?), NOT NULL, allow duplicates
expires - datetime code

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

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

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

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

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

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


5

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


4

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


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

1
টিম জ্যানসনের উত্তরটি হ্যাশ তৈরির জন্য একটি ভাল পদ্ধতির বর্ণনা দিয়েছে যদিও এতে পাসওয়ার্ড না থাকলে আমি নিরাপদ বোধ করি
জানি হার্টিকাইনেেন

2

আমার সমাধানটি এরকম। এটি 100% বুলেটপ্রুফ নয় তবে আমি মনে করি এটি বেশিরভাগ ক্ষেত্রে আপনাকে রক্ষা করবে।

ব্যবহারকারী লগ ইন যখন সফলভাবে এই তথ্য সঙ্গে একটি স্ট্রিং তৈরি:

$data = (SALT + ":" + hash(User Agent) + ":" + username 
                     + ":" + LoginTimestamp + ":"+ SALT)

এনক্রিপ্ট করুন $data, টাইপ করুন HttpOnly এ এবং কুকি সেট করুন।

যখন ব্যবহারকারী আপনার সাইটে ফিরে আসে, এই পদক্ষেপগুলি তৈরি করুন:

  1. কুকি ডেটা পান। কুকির ভিতরে বিপজ্জনক চরিত্রগুলি সরান। এটি দিয়ে বিস্ফোরণ:চরিত্র ।
  2. বৈধতা পরীক্ষা করুন। কুকি যদি X দিনের চেয়ে বেশি বয়স্ক হয় তবে ব্যবহারকারীদের লগইন পৃষ্ঠাতে পুনর্নির্দেশ করুন।
  3. কুকি পুরানো না হলে; ডাটাবেস থেকে সর্বশেষ পাসওয়ার্ড পরিবর্তন সময় পান। ব্যবহারকারীর শেষ লগইনের পরে যদি পাসওয়ার্ড পরিবর্তন করা হয় তবে ব্যবহারকারীরা লগইন পৃষ্ঠাতে পুনর্নির্দেশ করুন।
  4. যদি পাসটি সম্প্রতি পরিবর্তন না করা হয়; ব্যবহারকারীর বর্তমান ব্রাউজার এজেন্ট পান। (বর্তমান ইউজারএজেন্টহ্যাশ == কুকিউজারআজেন্টহ্যাশ) কিনা তা পরীক্ষা করে দেখুন। যদি এজেন্টরা একই পদক্ষেপে থাকে তবে অন্যথায় লগইন পৃষ্ঠাতে পুনর্নির্দেশ করুন।
  5. সমস্ত পদক্ষেপ সফলভাবে পাস হলে ব্যবহারকারীর নাম অনুমোদন করে।

যদি ব্যবহারকারী সাইনআউট করে থাকেন তবে এই কুকিটি সরান। ব্যবহারকারী যদি পুনরায় লগইন করে তবে নতুন কুকি তৈরি করুন।


2

আমি যখন আপনার হ্যাকিংয়ের দরকার হয় তখন এটির এনক্রিপ্ট করা সংস্করণ হ'ল আমি কোনও কুকিতে এনক্রিপ্ট করা স্টোর সংরক্ষণের ধারণাটি বুঝতে পারি না। যদি আমি কিছু মিস করছি তবে মন্তব্য করুন।

আমি এই পদ্ধতিটি 'মনে রাখুন আমাকে' নিয়ে যাওয়ার বিষয়ে ভাবছি। আপনি যদি কোনও সমস্যা দেখতে পান তবে মন্তব্য করুন।

  1. "আমাকে মনে রাখুন" ডেটা সংরক্ষণ করতে একটি টেবিল তৈরি করুন - ব্যবহারকারীর টেবিলের সাথে পৃথক করুন যাতে আমি একাধিক ডিভাইস থেকে লগ ইন করতে পারি।

  2. সফল লগইনে (স্মরণে আমাকে টিক দেওয়া সহ):

    ক) এই মেশিনে ইউজারআইডি হিসাবে ব্যবহার করতে একটি অনন্য র্যান্ডম স্ট্রিং তৈরি করুন: বিগ ইউজারআইডি

    খ) একটি অনন্য এলোমেলো স্ট্রিং উত্পন্ন করুন: বিগকে

    c) একটি কুকি সংরক্ষণ করুন: bigUserID: bigKey K

    d) "আমাকে মনে রাখুন" সারণীতে, এর সাথে একটি রেকর্ড যুক্ত করুন: ইউজারআইডি, আইপি ঠিকানা, বিগ ইউজারআইডি, বিগকি

  3. লগইন প্রয়োজন এমন কিছু অ্যাক্সেস করার চেষ্টা করা থাকলে:

    ক) কুকিটি পরীক্ষা করুন এবং মেলানো আইপি ঠিকানার সাথে বিগ ইউজারআইডি এবং বিগকির জন্য অনুসন্ধান করুন

    খ) যদি এটি সন্ধান করে তবে ব্যক্তিটিকে লগ ইন করুন তবে ব্যবহারকারীর টেবিল "সফট লগইন" তে একটি পতাকা সেট করুন যাতে কোনও বিপজ্জনক ক্রিয়াকলাপের জন্য আপনি সম্পূর্ণ লগইন করার জন্য অনুরোধ করতে পারেন।

  4. লগআউটে, ব্যবহারকারীর জন্য সমস্ত "স্মরণ আমাকে" রেকর্ডটি মেয়াদ শেষ হয়ে গেছে হিসাবে চিহ্নিত করুন।

আমি যে দুর্বলতাগুলি দেখতে পাচ্ছি তা হ'ল;

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

হ্যালো, এবং এই উত্তরের জন্য ধন্যবাদ, আমি এটি পছন্দ করি। যদিও একটি প্রশ্ন: আপনাকে কেন 2 টি এলোমেলো স্ট্রিং তৈরি করতে হবে - বিগ ইউজারআইডি এবং বিগকি? আপনি কেন কেবল 1 টি উত্পন্ন করে ব্যবহার করবেন না?
জেরেমি বেলোলো

2
বিগকির একটি পূর্বনির্ধারিত সময়ের পরে মেয়াদ শেষ হয়ে যায়, তবে বিগ ইউজারআইডি তা দেয় না। বিগ ইউসারআইডি হ'ল একই আইপি ঠিকানায় আপনাকে বিভিন্ন ডিভাইসে একাধিক সেশন করার অনুমতি দেয়। আশা করি এটি উপলব্ধি করে - আমাকে এক মুহুর্তের জন্য ভাবতে হয়েছিল :)
এনিগমা প্লাস

এইচএমএকে থাকার একটি জিনিস হ'ল সাহায্য করতে পারে, আপনি যদি এইচএমএকে টেম্পার্ড করে দেখেন তবে আপনি অবশ্যই জানতে পারবেন যে কেউ কুকি চুরি করার চেষ্টা করেছিল, তবে আপনি প্রতিটি লগইন স্থিতি পুনরায় সেট করতে পারেন। আমি কি সঠিক?
সুরজ জৈন

2

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

এখানে চিত্র বর্ণনা লিখুন

আপনার যদি প্রশ্ন, প্রতিক্রিয়া বা পরামর্শ থাকে তবে আমি নিরাপদ অবিচ্ছিন্ন লগইন প্রয়োগের চেষ্টা করা নবাগতের প্রতিফলনের জন্য ডায়াগ্রামটি আপডেট করার চেষ্টা করব।


0

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

আমি আপনাকে "কেন 2 দিন? 2 সপ্তাহের জন্য কেন" জিজ্ঞাসা করতে পারি? এর কারণ পিএইচপি-তে একটি সেশন ব্যবহার করে স্বয়ংক্রিয়ভাবে মেয়াদ শেষ হয়ে যাবে। কারণ পিএইচপি-তে একটি সেশনের মেয়াদ শেষ হওয়া আসলে অলস সময়সীমা।

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


1
একটি দীর্ঘ অধিবেশন সেট করা সম্ভবত খারাপ কারণ এটি সার্ভারের সংস্থানগুলি অপচয় করে এবং এটি কার্যকারিতাটিকে বিরূপ প্রভাবিত করবে
ব্যবহারকারী 3091530

0

আমি মনে করি আপনি কেবল এটি করতে পারেন:

$ কুকিস্ট্রিং = পাসওয়ার্ড_হ্যাশ ($ ব্যবহারকারীর নাম, PASSWORD_DEFAULT);

ডিবিতে কুকিস্ট্রিং সঞ্চয় করুন এবং এটি কুকি হিসাবে সেট করুন। এছাড়াও কুকি হিসাবে ব্যক্তির ব্যবহারকারীর নাম সেট করুন। হ্যাশের পুরো বিষয়টি হ'ল এটিকে বিপরীত ইঞ্জিনিয়ারিং করা যায় না।

যখন কোনও ব্যবহারকারী সরে আসে, অন্য কুকিস্ট্রিংয়ের চেয়ে এক কুকির থেকে ব্যবহারকারীর নামটি পান। যদি $ কুকি স্ট্রিং ডিবিতে সঞ্চিত একটির সাথে মিলে যায় তবে ব্যবহারকারী প্রমাণীকরণযোগ্য। যেহেতু পাসওয়ার্ড_হ্যাশ প্রতিবার আলাদা লবণ ব্যবহার করে, স্পষ্ট পাঠ্যটি কী তা সম্পর্কিত তা অপ্রাসঙ্গিক।

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