ما خوارزمية التشفير هو الأفضل لتشفير ملفات تعريف الارتباط ؟

Question

لأن هذا السؤال هو شعبية بدلا من ذلك, أعتقد أنه من المفيد أن تعطيه التحديث.

اسمحوا لي أن أؤكد الجواب الصحيح كما قدمها طماع على هذا السؤال:

يجب عدم تخزين أي بيانات تحتاج تشفير في ملف تعريف الارتباط. بدلا من ذلك, تخزين جيدة الحجم (128 بت/16 بايت) مفتاح عشوائي في كوكي و تخزين المعلومات التي تريد الاحتفاظ بها آمنة على الملقم التي تم تحديدها بواسطة كوكي الرئيسية.

---

أنا أبحث عن معلومات عن 'أفضل' خوارزمية التشفير لتشفير ملفات تعريف الارتباط.

أنا hava المتطلبات التالية:

• يجب أن تكون سريعة
  تشفير و فك تشفير البيانات سيتم القيام به ل (تقريبا) كل طلب

• وسوف تعمل على مجموعات البيانات الصغيرة ، عادة سلاسل من حوالي 100 حرف أو أقل

• يجب أن تكون آمنة ، ولكن انها ليست مثل نحن تأمين المعاملات المصرفية

• نحن بحاجة إلى أن تكون قادرة على فك تشفير المعلومات حتى SHA1 و الخارج.

الآن لقد قرأت أن السمكة المنتفخة هو سريع وآمن ، لقد قرأت أن AES سريعة وآمنة.مع السمكة المنتفخة وجود أصغر حجم الكتلة.

أعتقد أن كلا من الخوارزميات أكثر من كافية الأمن ؟ وبالتالي فإن السرعة ثم تصبح عاملا حاسما.ولكن أنا حقا ليس لدي أي فكرة إذا كانت هذه الخوارزمية هي مناسبة الصغيرة سلسلة الأحرف و إذا كان هناك ربما أفضل خوارزمية تشفير ملفات تعريف الارتباط.

لذا سؤالي هو:
ما خوارزمية التشفير هو أفضل تشفير الكوكيز البيانات ؟

التحديث
أن تكون أكثر دقة ، نريد تشفير 2 كوكي:واحد مع الدورة والمعلومات الأخرى مع 'تذكر لي معلومات.

منصة PHP وحدة اباتشي على لينكس على VPS.

تحديث 2
أنا أتفق مع كليتوس أن تخزين المعلومات في ملف تعريف الارتباط هو انعدام الأمن.

ولكن لدينا شرط لتنفيذ 'تذكر لي' الميزة.المقبولة طريقة للذهاب نحو هذا عن طريق وضع ملف تعريف الارتباط.إذا كان العميل يعرض ملف تعريف الارتباط هذا ، أنه أو أنها يسمح الوصول إلى نظام (تقريبا) المساواة في الحقوق كما لو أنه/أنها قدمت صالحة اسم المستخدم وكلمة السر.

لذلك نحن على الأقل ترغب في تشفير جميع البيانات المخزنة في ملف تعريف الارتباط بحيث:
أ) المستخدمين لا يمكن قراءة محتويات
ب) الخبيثة لا يمكن للمستخدمين افتعال الخاصة بهم كوكي أو العبث بها.

(جميع البيانات من ملفات تعريف الارتباط هي مطهرة و التحقق من صحة قبل أن تفعل أي شيء معها ، ولكن تلك قصة أخرى)

ملف تعريف ارتباط جلسة يحتوي على sessionId/الطابع الزمني لا شيء أكثر من ذلك.ربما يمكن أن تستخدم من دون تشفير, ولكن لا أرى أي ضرر في تشفير ؟ (من غير حساب الوقت).

ذلك بالنظر إلى أن لدينا لتخزين بعض البيانات في ملف تعريف الارتباط, ما هي أفضل طريقة لتشفير ؟

تحديث 3
الردود على هذا السؤال جعلني إعادة النظر في النهج الذي تم اختياره.أنا يمكن أن تفعل الشيء نفسه دون الحاجة إلى التشفير.بدلا من تشفير البيانات ، يجب أن ترسل البيانات التي لا معنى لها دون ذلك في سياق ولا يمكن تخمينها.

ومع ذلك أنا أيضا في حيرة:
ظننت أن التشفير مكنتنا من إرسال البيانات إلى BigBadWorld tm و لا يزال (إلى حد ما) التأكد من أن لا أحد يمكن أن يقرأ أو العبث به...
لم يكن هذا الهدف من التشفير ؟

ولكن ردود الفعل أدناه دفع نحو:لا تثق التشفير لتحقيق الأمن.

ما أنا في عداد المفقودين ؟ ؟

Answer 1

لا يوجد سبب حقيقي لا تذهب مع AES مع 256 بت.تأكد من استخدام هذا في CBC الوضعية ، , و PKCS#7 الحشو.كما قلت وسريعة وآمنة.

لقد قرأت (لم تختبر) أن السمكة المنتفخة قد يكون هامشيا أسرع...ومع ذلك المنتفخة لديه عيب رئيسي من الإعداد الطويل الذي جعلها سيئة على الوضع الخاص بك.أيضا, AES هو أكثر "ثبت".

هذا يفترض أنه حقا هو من الضروري بشكل متناظر تشفير بيانات ملف تعريف الارتباط.كما ذكر آخرون أنه حقا لا ينبغي أن يكون من الضروري ، وهناك فقط عدد قليل من الحالات الحافة حيث لا يوجد خيار آخر سوى ذلك.عادة سيكون أفضل تناسب لك بتغيير تصميم و العودة إما عشوائي الدورة معرفات ، أو إذا دعت الضرورة-طريقة التجزئة (باستخدام SHA-256).
في الحالة الخاصة بك ، إلى جانب "العادية" عشوائية الدورة معرف المشكلة هو "تذكرني" ميزة هذا وينبغي أيضا تنفيذ إما:

• طويل رقم عشوائي ، وتخزينها في قاعدة البيانات و التي تم تعيينها إلى حساب مستخدم ؛
• أو مرتبطا التجزئة (مثلHMAC) تتضمن على سبيل المثالاسم المستخدم الزمني ، mebbe الملح و سر الخادم الرئيسية.هذا يمكن بالطبع جميع التحقق من جانب الخادم...

يبدو أننا خرجنا قليلا عن الموضوع الأصلي, سؤال محدد و غيرت أساس السؤال الخاص بك عن طريق تغيير التصميم....
لذلك طالما نحن نفعل ذلك, وأود أن نوصي بشدة ضد هذه الميزة الثابتة "تذكرني" ، لعدة أسباب ، وأكبر من بينها:

• يجعل من المرجح أكثر أن أحدا قد يسرق المستخدم تذكر الرئيسية ، مما يسمح لهم بانتحال هوية المستخدم (ثم ربما تغيير كلمة المرور) ؛
• CSRF - عبر الموقع طلب التزوير.الميزة سوف تسمح بشكل فعال مجهول المهاجم تسبب عارف للمستخدمين إرسال "مصادقة" يطلب التطبيق الخاص بك حتى دون أن تكون فعلا تسجيل الدخول.

Answer 2

هذا هو لمس على مسألتين منفصلتين.

أولا ، اختطاف الدورة.هذا هو فيها طرف ثالث يكتشف ان مصادقة كوكي و مكاسب الوصول إلى شخص آخر التفاصيل.

ثانيا ، هناك دورة أمن البيانات.هذا يعني أنه يمكنك تخزين البيانات في ملف تعريف الارتباط (مثل اسم المستخدم).هذه ليست فكرة جيدة.أي من هذه البيانات هي في الأساس غير جديرة بالثقة تماما مثل نموذج HTML البيانات غير موثوق به (بغض النظر عن جافا سكريبت التحقق من صحة و/أو HTML طول القيود التي تستخدمها ، إن وجدت) لأن العميل مجانا على تقديم ما يريدون.

غالبا ما ستجد الناس (بحق) الدعوة إلى التعقيم HTML استمارة البيانات ولكن كوكي البيانات سوف تكون عمياء قبولها على علاتها.خطأ كبير.في الحقيقة, أنا لا تخزن أي معلومات في ملف تعريف الارتباط.بل الدورة الرئيسية و هذا كل شيء.

إذا كنت تنوي تخزين البيانات في ملف تعريف الارتباط أنصحك بشدة إلى إعادة النظر.

تشفير هذه البيانات لا تجعل المعلومات أكثر trustworth لأن التشفير المتناظر هو عرضة هجوم القوة الغاشمة.من الواضح AES-256 أفضل مما نقول, DES (هيه) ولكن 256-بت من الأمن لا يعني بالضرورة بقدر ما كنت أعتقد أنه لا.

لشيء واحد, الأملاح عادة إنشاؤها وفقا خوارزمية أو عرضة للهجوم.

على آخر بيانات ملف تعريف الارتباط هو مرشح لمنصب رئيس الوزراء سرير الهجمات.إذا كان يعرف أو يشتبه في أن اسم المستخدم في تشفير البيانات هناك سرير طفلك.

وهذا يعيدنا إلى النقطة الأولى:اختطاف.

وتجدر الإشارة إلى أن على المشترك بيئات استضافة في بي (كمثال) بيانات جلسة العمل الخاصة بك هو ببساطة المخزنة على الملفات و هو قابل للقراءة من قبل أي شخص آخر على نفس المضيف على الرغم من أنها لا تعرف بالضرورة أي موقع هو.لذلك أبدا متجر عادي كلمات السر وأرقام بطاقات الائتمان واسعة تفاصيل شخصية أو أي شيء التي قد تعتبر حساسة في الدورة البيانات في مثل هذه البيئات دون شكل من أشكال التشفير أو الأفضل من ذلك ، فقط تخزين رئيسي في الدورة وتخزين الفعلي البيانات الحساسة في قاعدة بيانات.

ملاحظة: أعلاه ليست فريدة من نوعها PHP.

ولكن هذا من جانب الخادم التشفير.

الآن هل يمكن القول بأن تشفير جلسة مع بعض البيانات الإضافية سوف تجعل أكثر أمنا من الخطف.مثال شائع هو عنوان IP الخاص بالمستخدم.المشكلة هي أن العديد من الناس يستخدمون نفس جهاز الكمبيوتر/الكمبيوتر المحمول في كثير من مواقع مختلفة (على سبيل المثال النقاط الساخنة واي فاي, عمل, المنزل).أيضا العديد من البيئات سوف تستخدم مجموعة متنوعة من عناوين IP مثل عنوان المصدر ، لا سيما في بيئات الشركات.

قد أيضا استخدام عامل المستخدم ولكن هذا تخمينها.

لذلك حقا ، بقدر ما استطيع ان اقول لا يوجد سبب حقيقي استخدام ملف تعريف الارتباط تشفير على الإطلاق.لم أعتقد أن هناك لكن في ضوء هذا السؤال ذهبت تبحث ثبت إما صحيحة أو خاطئة.وجدت بعض المواضيع عن الناس مما يشير إلى طرق لتشفير بيانات ملف تعريف الارتباط وشفافية تفعل ذلك مع وحدات أباتشي ، وهلم جرا ولكن كل هذه يبدو بدافع حماية البيانات المخزنة في ملف تعريف الارتباط (الذي imho لا يجب أن تفعل).

لم أرى الحجة الأمنية لتشفير ملف تعريف الارتباط التي لا تمثل شيئا أكثر من مفتاح جلسة العمل.

أنا سعيدة أن ثبت خطأ إذا كان شخص ما يمكن أن نشير شيئا بل على العكس.

Answer 3

تحذير الأمان:هذه اثنين من وظائف غير آمنة.انهم يستخدمون وضع البنك المركزي الأوروبي وتفشل مصادقة المشفر.انظر هذا الجواب أفضل طريقة للمضي قدما.

تلك القراءة من خلال الرغبة في استخدام هذا الأسلوب في مخطوطات PHP.هنا هو على سبيل المثال العمل باستخدام 256bit ريجنديل (لا AES).

function encrypt($text, $salt) 
{ 
    return trim(base64_encode(mcrypt_encrypt(MCRYPT_RIJNDAEL_256, $salt, $text, MCRYPT_MODE_ECB, mcrypt_create_iv(mcrypt_get_iv_size(MCRYPT_RIJNDAEL_256, MCRYPT_MODE_ECB), MCRYPT_RAND)))); 
} 

function decrypt($text, $salt) 
{ 
    return trim(mcrypt_decrypt(MCRYPT_RIJNDAEL_256, $salt, base64_decode($text), MCRYPT_MODE_ECB, mcrypt_create_iv(mcrypt_get_iv_size(MCRYPT_RIJNDAEL_256, MCRYPT_MODE_ECB), MCRYPT_RAND))); 
}

ثم حفظ ملف تعريف الارتباط

setcookie("PHPSESSION", encrypt('thecookiedata', 'longsecretsalt'));

وقراءة في الصفحة التالية:

$data = decrypt($_COOKIE['PHPSESSION'], 'longsecretsalt');

Answer 4

يمكنك تحقيق ما تريد بشكل آمن باستخدام AES في EAX الوضعية.النص المشفر سوف تكون أكبر من عادي;هذا طبيعي بالنسبة التشفير الآمن.

المهاجم بالطبع معرفة طول عادي من النص المشفر, ولكن لا ينبغي أن تكون قادرة على تحديد أي شيء آخر.

توليد مفاتيح AES بشكل عشوائي.

تأكد من استخدام الطازجة حالية لكل التشفير و استخدام "البيانات المرتبطة" الميدان لضمان أن أي شيء يمكنك تشفير لغرض واحد لا تقدم نفسها على أنها آخر (مثل اسم المستخدم و اسم ملف تعريف الارتباط يمكن أن تذهب إلى هناك)

ردود الفعل أدناه دفع نحو:هل لا تثق التشفير لإنجاز الأمن.

المزيد "إذا كنت لا تشفير الخبراء سوف نقلل كم هو سهل الحصول على خطأ".على سبيل المثال ، AFAICT لا أحد آخر في هذا الموضوع قد نوقش تسلسل وسائط أو سلامة الرسالة ، والتي تغطي اثنين المشتركة المبتدئين الأخطاء.

Answer 5

سريع تشفير ملفات تعريف الارتباط مع Libsodium

إذا كنت في حاجة سريعة وآمنة تشفير ملفات تعريف الارتباط في PHP, تحقق من كيف الهاليت تطبق عليها.الهاليت تعتمد على على libsodium PECL امتداد لتوفير تأمين التشفير.

<?php
use \ParagonIE\Halite\Cookie;
use \ParagonIE\Halite\Symmetric\Key;
use \ParagonIE\Halite\Symmetric\SecretKey;

// You can also use Key::deriveFromPassword($password, $salt, Key::CRYPTO_SECRETBOX);
$encryption_key = new SecretKey($some_constant_32byte_string_here);

$cookie = new Cookie($encryption_key);

$cookie->store('index', $any_value);
$some_value = $cookie->fetch('other_index');

إذا لم تتمكن من تثبيت PECL امتداد اطلب من مسؤول النظام أو موفر استضافة تفعل ذلك بالنسبة لك.إذا رفضوا, لا يزال لديك خيارات.

---

تأمين تشفير ملفات تعريف الارتباط في PHP, عقد الملح من فضلك

إجابات أخرى ترشدك إلى تشفير البيانات الخاصة بك مع بينسل أو mcrypt لكنهم في عداد المفقودين خطوة حاسمة.إذا كنت ترغب في بأمان تشفير البيانات في PHP, ، يجب أن مصادقة الرسائل الخاصة بك.

تستخدم OpenSSL تمديد عملية تحتاج إلى متابعة يبدو مثل هذا:

---

الديباجة

• (قبل أن تفكر حتى في التشفير) تولد 128 بت ، 192 بت أو 256 بت سلسلة عشوائية.وسوف يكون هذا المفتاح الرئيسي.

  لا تستخدم للقراءة البشرية كلمة المرور. إذا كنت لسبب ما ، يجب أن استخدام الإنسان للقراءة كلمة السر, نسأل التشفير SE للحصول على إرشادات.

  إذا كنت تحتاج إلى عناية خاصة ، يا رب تكنولوجيا خدمات استشارية, بما في ذلك تطوير الترميز الميزات.

التشفير

1. توليد عشوائي التهيئة ناقلات (IV) أو حالية.على سبيل المثال random_bytes(openssl_cipher_iv_length('aes-256-cbc'))
2. استخدام HKDF أو مماثل خوارزمية تقسيم المفتاح الرئيسي الخاص بك إلى اثنين من مفاتيح:
   1. مفتاح تشفير ($eKey)
   2. مفتاح المصادقة ($aKey)
3. تشفير السلسلة openssl_encrypt() مع الرابع و مناسب modate (مثلا ، aes-256-ctr) باستخدام مفتاح التشفير ($eKey) من الخطوة 2.
4. حساب مصادقة الوسم من النص المشفر من الخطوة 3 باستخدام مرتبطا وظيفة تجزئة مثل HMAC-SHA256.على سبيل المثال hash_hmac('sha256', $iv.$ciphertext, $aKey). من المهم جدا أن المصادقة بعد التشفير ، لتغليف الرابع/حالية أيضا.
5. حزمة المصادقة العلامة الرابع أو حالية ، المشفر معا اختياريا ترميز مع bin2hex() أو base64_encode().(تحذير:هذا النهج قد تسرب ذاكرة التخزين المؤقت-توقيت المعلومات.)

فك التشفير

1. تقسيم المفتاح الخاص بك ، كما في الخطوة 2 في التشفير.نحن بحاجة إلى نفس مفتاحين خلال فك التشفير!
2. (اختياريا ، فك و) فك ماك, الرابع, و المشفر من معبأة الرسالة.
3. التحقق من مصادقة الوسم عن طريق إعادة حساب HMAC من الرابع/حالية و المشفر مع المستخدم المقدمة HMAC باستخدام hash_equals().
4. إذا و فقط إذا كان الخطوة 3 يمر, فك تشفير النص المشفر باستخدام $eKey.

إذا كنت تريد أن ترى كيف يبدو كل شيء معا ، انظر هذا الجواب الذي يحتوي على نموذج التعليمات البرمجية.

إذا كان هذا يبدو مثل الكثير من العمل ، فتيل/php-التشفير أو زند-crypt ويطلق عليه اليوم.

---

تذكر لي ملفات تعريف الارتباط

ولكن لدينا شرط لتنفيذ 'تذكر لي' الميزة.المقبولة طريقة للذهاب نحو هذا عن طريق وضع ملف تعريف الارتباط.إذا كان العميل يعرض ملف تعريف الارتباط هذا ، أنه أو أنها يسمح الوصول إلى نظام (تقريبا) المساواة في الحقوق كما لو أنه/أنها قدمت صالحة اسم المستخدم وكلمة السر.

التشفير هو في الواقع ليس الأداة الصحيحة لهذا العمل.كنت تريد أن تتبع هذه العملية امن تذكر لي ملفات تعريف الارتباط في PHP:

توليد تذكر لي رمزية

1. إنشاء اثنين من سلاسل عشوائية:
   1. A selector التي سيتم استخدامها في قاعدة بيانات البحث.(الغرض من عشوائية محدد بدلا من مجرد معرف متسلسلة هو لا تسرب كم عدد المستخدمين النشطين على موقع الويب الخاص بك.إذا كنت مرتاحا تسريب هذه المعلومات لا تتردد في مجرد استخدام معرف متسلسلة.)
   2. A validator والتي سيتم استخدامها لمصادقة المستخدم تلقائيا.
2. حساب تجزئة validator (بسيط التجزئة SHA-256 تكفي).
3. تخزين selector و تجزئة validator في جدول قاعدة بيانات محفوظة التلقائي تسجيل الدخول.
4. تخزين selector و validator في ملف تعريف ارتباط على الكمبيوتر العميل.

التعويض تذكر لي رمزية

1. تقسيم واردة كوكي في selector و validator.
2. إجراء بحث قاعدة بيانات (استخدام أعدت البيانات!) على أساس selector.
3. إذا كان الصف العثور على حساب تجزئة validator.
4. قارن تجزئة المحسوبة في الخطوة 3 مع تجزئة المخزنة في قاعدة البيانات مرة أخرى باستخدام hash_equals().
5. إذا الخطوة 4 بإرجاع true, تسجيل المستخدم في الحساب المناسب.

وهذه هي الاستراتيجية التي البواب اعتمد على المدى الطويل مصادقة المستخدم و هو الأكثر أمانا الاستراتيجية المقترحة حتى الآن عن تلبية هذا المطلب.

Answer 6

في حين أن كلا قوية جدا منها ، AES هو المعيار.

أما بالنسبة الأمن من قطع صغيرة من البيانات:أصغر - كلما كان ذلك أفضل.أقل تشفير البيانات يتعرض أطول يمكنك استخدام المفتاح.هناك دائما النظري الحد من كمية البيانات التي يمكن أن تكون مشفرة في مفتاح واحد من الخوارزمية دون تعريض النظام إلى المخاطر.

Answer 7

إذا قمت بتشفير ملف تعريف الارتباط ، الخادم لا يزال لديه لفك إلى قراءتها (للتحقق من نفس المفتاح) ، وبالتالي أي تشفير الكوكيز لا طائل لأنه لو سرقت (الأمم المتحدة-تحرير) وسوف لا يزال يؤدي القراصنة مباشرة إلى حسابك.فقط غير آمنة كما لا تشفير على الإطلاق.

أعتقد أن المشكلة الحقيقية من شخص سرقة ملفات تعريف الارتباط هي العلاقة بين الخادم و العميل.استخدام اتصال SSL التي يقدمها المضيف الخاص بك.

أما بالنسبة الكعكة الخاصة بك, كنت بحاجة لجعل عشوائي طويلة id لكل مستخدم في قاعدة البيانات (قد تغير كل تسجيل الدخول) فقط مجموعة أن مثل الكعكة أو الدورة.كوكي الذي يحتوي على مفتاح يمكن التحقق منها عن طريق php و إذا كان يساوي حساب أو جدول في قاعدة البيانات الخاصة بك ، تفريغ البيانات على صفحة ويب مثل العادية.

Answer 8

كما أشار إلى ذلك عدة مرات في التعليقات السابقة ، يجب أن تطبيق حماية النزاهة إلى أي المشفر أن ترسل إلى المستخدم وتقبل مرة أخرى.وإلا فإن البيانات المحمية يمكن تعديلها ، أو مفتاح التشفير استردادها.

وخاصة PHP من الأمثلة السيئة التي تتجاهل هذا (انظر PHP التشفير - المضي قدما مع الرعاية) ولكن هذا لا ينطبق على أي لغة.

واحدة من عدد قليل من الأمثلة الجيدة التي رأيت PHP-CryptLib والذي يستخدم جنبا إلى جنب التشفير-وضع مصادقة للقيام بهذه المهمة.بايثون pyOCB يوفر وظائف مماثلة.

Answer 9

لماذا تريد تشفير الكوكيز ؟

كما أرى ، هناك نوعان من الحالات:إما أن تعطي العميل مفتاح أو لا.

إذا كنت لا تعطي مفتاح العميل ، ثم لماذا يتم منحهم البيانات ؟ إلا إذا كنت تلعب لعبة غريبة مع كسر تشفير ضعيف (التي كنت صراحة لا) ، قد وكذلك تخزين البيانات على الخادم.

إذا كنت هل من ناحية العميل الرئيسية ، ثم لماذا قمت بتشفيرها في المقام الأول ؟ إذا كنت لا تشفير الاتصالات الرئيسية ، ثم تشفير الكوكيز الصورية:MITM يمكن أن ننظر في تعريف الارتباط و نرسل لك أي تعريف الارتباط يريد.إذا كنت تستخدم قناة مشفرة إلى العميل ، لماذا الحمل الزائد من تشفير البيانات المخزنة?

إذا كنت قلقا حول المستخدمين الآخرين على الجهاز العميل قراءة ملف تعريف الارتباط ، والتخلي وتحمل المتصفح مجموعات جيد إذن بت :)

Answer 10

AES (المعروف أيضا باسم ريجنديل) هو الأكثر شعبية.كتلة حجم 128-بت فقط من 16 بايت و أنت تتحدث "نحو 100 من الشخصيات".

Answer 11

أعتقد أن "إعطاء بعيدا" أي تشفير البيانات حتى عندما يكون حول اسم المستخدم وكلمة المرور ليست جيدة ...هناك العديد من شبيبة يمكن أن تشمه ...أقترح عليك إنشاء المستخدمين في DB الجدول حقل cookie_auth أو أيا كان ...

بعد تسجيل الدخول أولا جمع :الحالية:متصفح, IP,ans بعض الملح الخاص الرئيسية ، بالإضافة إلى اسم المضيف الخاص بك فار ...

إنشاء متجر تجزئة في هذا المجال ...تعيين ملف تعريف الارتباط ...عندما كوكي "يستجيب" مقارنة بين جميع تلك المخزنة تجزئة به ...

حتى إذا كان شخص ما "سرقة" ملف تعريف الارتباط لن يكون قادرا على استخدامها :-)

آمل أن يساعد هذا :-)

feha الرؤية.إلى

Answer 12

بالإضافة إلى ذلك, لقد حاولت mcrypt_encrypt وشيء واحد يرجى أن نضع في اعتبارنا.إذا كنت تفعل base64_encode(mcrypt_encrypt(...)).

ثم بعد ذلك تفعل base64_decode و إخراج البيانات المشفرة (echo).ربما سوف يكون مشدود و لا نرى أي شيء.ومع ذلك ، إذا كنت تفعل mcrypt_decrypt( ... base64_decode($value) ).سوف ترى البيانات الأصلية.