ميزة مصادقة "تذكر" ، هل تعني دائمًا موقع "غير آمن"؟

Question

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

Gmail, فيسبوك والبعض الآخر لديه هذا النوع من الميزة ، لكنني لست متأكدًا من مدى أمانها.

إطار Java مثل أمن الربيع يستخدم "نهج الرمز المميز القائم على التجزئة". يتم تخزين الرمز المميز الذي يتم إنشاؤه (باستخدام اسم المستخدم وكلمة المرور ووقت انتهاء الصلاحية و Privatekey) في ملفات تعريف الارتباط الخاصة بالعميل "Token = 567 WhateAding567". ثم تتم إعادة استخدام الرمز المميز لإعادة مصادقة المستخدم في المرة القادمة التي يعود فيها.

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

في الأساس الجميع يمكن قراءة الرمز المميز وإعادة استخدامه للمصادقة.

أحاول إلقاء نظرة على كيفية تنفيذ Gmail أو Facebook هذه الوظيفة. أستطيع أن أرى بعض ملفات تعريف الارتباط مثل "الوجود = DJ267619445G09H0L15228675 ..... 'في FB ، والبعض الآخر في Gmail.
لست متأكدًا جدًا مما إذا كانوا يستخدمون بعض الخدعة الأخرى للحماية من شخص يحاول انتحال شخصية بعض المستخدمين الآخرين.

سأحاول انتحال نفسي باستخدام شيء مثل لفة لمعرفة ما إذا كانوا يستخدمون رمزًا محددًا فقط لتذكر المستخدم.
إذا كانوا يبدو لي مثل مشكلة أمنية كبيرة. ربما ليس Facebook (لا أهتم به) ولكن مع Gmail إذا لم تقم بتعيين "استخدام دائما https"سيتم استخدام اتصال HTTP وسيقوم بإرسال الرموز المميزة غير المشفرة عبر الإنترنت.
ما رأيك؟

لقد لاحظت أيضًا أن حقول اسم المستخدم/كلمة المرور على Facebook تتعرض تحت HTTP (وليس HTTPS). في هذا الصدد ، أتساءل أيضًا: هل جميع مواقع الويب التي تعرض حقل اسم المستخدم/كلمة المرور عبر HTTP Unsecure "بطبيعتها". بمجرد إرسال الطلب عبر HTTP ، لا يوجد "إعادة توجيه إلى HTTPS" يمكنه إصلاح مشكلة "بيانات الاعتماد المرئية للعالم".

شكرًا

تعديل:
تم تأسيس قلقي جيدًا http://codebutler.com/
بفضل firesheep المبدعون لتسليط الضوء على المشكلة !!!

Answer 1

إنها ليست مشكلة في تنفيذ تذكر. ما عليك القيام به هو الحفاظ على الجلسة حية لفترة طويلة (وتعيين ملف تعريف الارتباط إلى فترة طويلة). حتى Gmail سوف يسجلك بعد فترة معينة (أعتقد أنه أسبوعين أو شهر). ومع ذلك ، تحتاج إلى إدراك أن الحفاظ على نفس الجلسة مفتوحة لفترة أطول يزيد من إمكانية الاختطاف فيها. كإجراء مضاد ، تحتاج إلى زيادة قوة معرف الجلسة الخاص بك. معرف الجلسة هو المعرف الموجود في ملف تعريف الارتباط (أو في URI كما هو شائع في بعض البرامج باسم "file.php؟ phpsessid = 1234 ...").

المفتاح هو الحفاظ على معرف جلسة قوي. على سبيل المثال ، في Gmail ، لديك ملف تعريف ارتباط GX بقيمة مماثلة لقيمة

DQAAAJoAAAA8mnjaAwgkS7y8Ws5MYCl-PAQLp9ZpMXpGKR47z4L9mlBH-4qEyApAtFbnLkzv1pPqxua1hOWMGiKYpBZr-h7Icyb-NUUg2ZW_nUFIymvw9KjmjSECYTowbCsDerkAxCzSDa83b5YC1mykPv1a9ji4znt6Fsna-AKgNTntvmUxeJ92ctsSlg9iGySEmXnisVyyJiQvI8jzbZqSpE_N2RKZ

السبب في أن اختطاف الجلسة مستحيل إلى حد كبير ، لأن معرف الجلسة قوي للغاية ، ولأن الموقع يستخدم HTTPS في كل مكان. لا يمكن لأحد أن يخمن أو الحصول على معرف الجلسة الخاص بك بطريقة أخرى (وبالتالي لا يمكن اختطافه في جلستك). على نظرة سريعة ، يبدو أن معرف الجلسة أعلاه يحتوي على ~ 1250 بت إلى حد ما من القوة ، 1*10^376 إمكانيات مختلفة. لا أحد يستطيع تخمين ذلك.

من الواضح أنه سيكون هناك دائمًا طرق محتملة للاختطاف في الجلسة. على سبيل المثال ، تفتح نقاط الضعف XSS طريقة الباب للحصول على ملفات تعريف الارتباط الخاصة بك ، وبالتالي معرف الجلسة الخاص بك ، ولكن هذا ليس خطأ جلساتك بأي شكل من الأشكال ، وليس له أي علاقة بـ "تذكر".

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

إذا قمت بتعيين علامة Cookie Secure على True أثناء وجودها في HTTPS ، فلن يتم إرسال ملف تعريف الارتباط أبدًا عند الوصول إلى الموقع عبر HTTP. إنه أمر لا بد منه لمواقع HTTPS فقط.

بشكل عام ، يبدو أن الناس يستخدمون HTTPS فقط لصفحة تسجيل الدخول ، وهو أمر خاطئ. إذا كان المرء يهتم حقًا ، فيجب عليه استخدام HTTPS في جميع أنحاء الصفحة. خلاف ذلك ، من المستحيل منع جميع محاولات اختطاف الجلسة.

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

ربما ليس Facebook (لا أهتم به) ولكن مع Gmail إذا لم تقم بتعيين "استخدم دائمًا HTTPs" ، فسيتم استخدام اتصال HTTP وسيقوم بإرسال الرموز غير المشفرة عبر الإنترنت. ما رأيك؟

أعتقد أن القيمة يجب أن تكون افتراضية لـ HTTPS في جميع الحالات إن أمكن. السبب الحقيقي الوحيد لسبب عدم استخدام HTTPS هو المال (= الأداء/الأجهزة).

Answer 2

يطلق عليه بشكل عام هجوم إعادة. يعيد المهاجم طلبًا باستخدام بيانات الاعتماد نفسها (على سبيل المثال ملف تعريف الارتباط) الذي سرقه منك ، وهو قادر على انتحال شخصية لك. هجوم XSS هو مجرد تباين في هذا ، ولكن يمكن الوقاية منه (على سبيل المثال باستخدام httponly).

الطريقة الوحيدة لتخفيف معظم هجمات إعادة التشغيل هي HTTPS في كل مكان. يجب أن تبقي معظم عيون المتطفلين.

هناك الكثير من تقنيات الوقاية جدا.

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

في ASP.NET 2.0+ ، عند استخدام مصادقة النماذج ، يمكنك تحديد requireSSL='true' للإشارة إلى أن المتصفحات يجب أن ترسل ملف تعريف الارتباط المصادقة فقط عند إجراء اتصال HTTPS. يرى هذه المقالة MSDN لمزيد من المعلومات حول تأمين مصادقة النماذج.

---

السبب الوحيد لعدم السماح remember me هو إذا كنت مصرفيا أو تطبيقًا مشابهًا. إذا لم تكن كذلك ، فقط اتبع بعض القواعد البسيطة:

1. اذا كنت تمتلك remember me, ، ضع انتهاء صلاحية على ملف تعريف الارتباط في أكثر من 30 يومًا في المستقبل ولا تنزلق القيمة. إجبار المستخدم على تسجيل الدخول مرة واحدة في الشهر ليس سيئًا للغاية.
2. أي عمليات حساسة تطلب كلمة السر. عند تحديث الفواتير أو بطاقات الائتمان أو تفاصيل الحساب دائماً إعادة تكوين كلمة مرور المستخدمين. عادةً ما يكون الشكل الأكثر احتمالًا من سوء المعاملة عبر نفس الكمبيوتر الذي يستخدمه الشخص ، لكنه يضمن أيضًا أنه حتى ملف تعريف الارتباط المصادقة المسروقة بمفرده لا يمكن أن يضر كثيرًا. يمكنك رؤية رصيدي ، لكن لا يمكنك نقل أي شيء.

Answer 3

أتفق مع معظم التعليقات المذكورة أعلاه. إذا كنت قلقًا بشأن الأمن ، فيجب عليك -

أ) استخدام HTTPS طوال الوقت. حتى Gmail تحولت مؤخرًا إلى استخدام HTTPS افتراضيًا - انظر http://gmailblog.blogspot.com/2010/01/default-https-access-for-gmail.html

ب) قم بتعيين العلم الآمن في ملف تعريف الارتباط للجلسة لمنع المتصفح من إرساله عبر اتصال HTTP.

ج) إصلاح XSS في التطبيق الخاص بك. إذا كان لديك مشكلات XSS ، فإن تنفيذ "تذكرني" سيكون دائمًا غير آمن. انظر ورقة الغش في الوقاية من OWASP.

بما في ذلك عنوان IP في معرف الجلسة لن يساعد. إن القيام بذلك سيجعل "تذكرني وظيفة" عديمة الفائدة إلى حد كبير ، ولا يضيف الكثير من الأمان. أعرف بالتأكيد أن Google لا تضع عناوين IP في معرف الجلسة.

Answer 4

الطريقة الوحيدة لجعل موقع آمن تمامًا هي تمكين HTTPS في كل مكان. أنت على حق ، يمكن استنشاق ملفات تعريف الارتباط واستخدامها لاحقًا في انتحال شخصية.

Answer 5

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

إذا نظرت إلى مصدر Facebook و Gmail وربما نماذج تسجيل الدخول إلى المواقع الأخرى ، فإن إجراء نموذج تسجيل الدخول يستخدم HTTPS ، والذي يعيد التوجيه إلى صفحة غير آمنة بمجرد أن تنجح تسجيل الدخول.

Answer 6

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

هل هذا واضح ؟

لم يستطع HTTPS فعل أي شيء إذا كان لديك هجوم XSS (أفضل طريقة لسرقة ملفات تعريف الارتباط)