https URL مع رمز المعلمة :كيف الآمن هو ؟
https://stackoverflow.com/questions/643355
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russianسؤال
على موقعنا, نحن نقدم للمستخدمين محاكاة على أساس المعلومات الخاصة بهم (في الشكل).نود أن تسمح لهم للحصول على نتائج المحاكاة في وقت لاحق ، ولكن دون إجبارهم على إنشاء تسجيل الدخول/كلمة مرور الحساب.
لقد فكرت في إرسال بريد إلكتروني مع وصلة, من التي يمكن أن تعود نتائجها.ولكن بطبيعة الحال يجب تأمين URL, لأن البيانات الخاصة على المحك.
لذلك نحن ينوي تمرير رمز (مثل 40 حرفا حروف و أرقام أو تجزئة MD5) في عنوان URL إلى استخدام SSL.
وأخيرا ، سوف تتلقى رسالة بريد إلكتروني مثل هذا:
مرحبا ،
نعود النتائج الخاصة بك على https://www.example.com/load_simulation?token=uZVTLBCWcw33RIhvnbxTKxTxM2rKJ7YJrwyUXhXn
ما رأيك في ذلك ؟ هو آمن بما فيه الكفاية ؟ ماذا تنصح لي رمز الجيل ؟ ماذا عن تمرير معلمات عنوان URL في https الطلب ؟
المحلول
وSSL ستحمي معلمات الاستعلام في العبور؛ ومع ذلك، البريد الالكتروني نفسها ليست آمنة، والبريد الإلكتروني يمكن أن ترتد على طول أي عدد من خوادم قبل الوصول إلى وجهتها.
وهذا يتوقف أيضا على خادم الويب الخاص بك URL الكامل قد تحصل على تسجيل في ملفات السجل الخاص به. اعتمادا على مدى حساسية البيانات قد لا ترغب شعبكم IT لها الوصول إلى جميع الرموز.
وبالإضافة إلى ذلك URL مع سلسلة الاستعلام سيتم حفظها في التاريخ المستخدم الخاص بك، مما يسمح للمستخدمين الآخرين من نفس الجهاز للوصول إلى URL.
وأخيرا وما يجعل هذا غير آمنة جدا هو، يتم إرسال URL في رأس التحويلية من جميع طلبات أي مورد، وحتى الموارد طرف ثالث. حتى إذا كان لديك استخدام Google Analytics على سبيل المثال، سوف ترسل جوجل الرمز المميز URL في كل ولهم.
في رأيي هذا هو فكرة سيئة.
نصائح أخرى
أود أن استخدام ملف تعريف الارتباط هذا.سير العمل يجب أن يكون مثل هذا:
- يدخل المستخدم إلى موقع الويب الخاص بك لأول مرة.
- موقع كوكي
- المستخدم بإدخال البيانات.يتم تخزين البيانات في قاعدة البيانات باستخدام الرئيسية التي يتم تخزينها في ملف تعريف الارتباط.
- عندما المستخدم الأوراق ، يمكنك إرسال لهم رسالة بالبريد إلكتروني مع https:الرابط
- عندما المستخدم يعود الموقع يكتشف كوكي و يمكن تقديم المستخدم مع البيانات القديمة.
الآن يريد المستخدم إلى استخدام متصفح آخر على جهاز آخر.في هذه الحالة تقدم "تحويل" الزر.عندما ينقر المستخدم على هذا الزر, أنها سوف تحصل على "عربون".أنها يمكن أن تستخدم هذا الرمز على جهاز كمبيوتر آخر إلى إعادة تعيين ملف تعريف الارتباط.وبهذه الطريقة ، يمكن للمستخدم أن تقرر كيفية تأمين تريد نقل مميز.
وSSL يؤمن محتويات البيانات في العبور، لكني لست متأكدة من URL.
وبغض النظر، طريقة واحدة لتخفيف مهاجم إعادة استخدام هذا المنوال URL للتأكد من كل رمز يمكن استخدامها مرة واحدة فقط. حتى انك تستطيع تحديد أحد هذه الملفات بحيث يمكن للمستخدم الشرعي مواصلة استخدام الرابط، ولكن بعد وصول الأول أنها ستعمل فقط لشخص ما مع ملفات تعريف الارتباط.
إذا تم المساس البريد الإلكتروني للمستخدم ومهاجم يحصل على الرابط أولا، حسنا، كنت مسقي. ولكن المستخدم لديه أيضا مشاكل أكبر.
والبريد الإلكتروني E-بطبيعته غير آمن. إذا كان أي شخص يمكن النقر على هذا الرابط والحصول على البيانات، وكنت لا تحمي حقا.
وحسنا الرمز المميز هو آمن عندما يتم تمريرها من خلال SSL. المشكلة التي ستكون لدينا هو أنه التقنى للناس (أولئك الذين ليس الغرض منه ل) من خلال قدرته على عرض URL.
إذا انها معلومات خاصة مثل SSN أنا لا أعتقد أنني سوف ترسل URL من خلال البريد الإلكتروني. كنت أود أن يكون بدلا منها إنشاء اسم مستخدم وكلمة مرور للموقع. فمن السهل جدا لتقديم تنازلات رسالة بريد إلكتروني مع هذا النوع من المعلومات على المحك بالنسبة لك ولهم. إذا تم comprimised حساب شخص انها ستدخل حيز لكم quesion الخطأ الذي هو عليه حقا. وأكثر أمنا والأفضل لك هي من وجهة نظر CYA بدقة.
وأنا حقا لا أن نعتبر أن آمنة بما فيه الكفاية لالحالة التي توجد فيها قضايا الخصوصية خطيرة. حقيقة أن كنت ترسل URL في (ويفترض نص واضح) البريد الإلكتروني هو إلى حد بعيد الحلقة الأضعف. بعد ذلك هو خطر هجمات القوة الغاشمة على الرموز، والتي (التي تفتقر إلى بنية آلية المصادقة الحقيقية) من المحتمل أن تكون أكثر عرضة للخطر من الإعداد اسم المستخدم وكلمة المرور التي شيدت بشكل جيد.
وليس هناك مشاكل على الإطلاق مع المعلمات في طلب HTTPS، بالمناسبة.
وكما هو الحال، فإنه سيكون فكرة سيئة. سوف يخدش الأمن مع سهولة الاستخدام. كما قال قبل SSL سيحمي فقط نقل المعلومات بين المتصفح الخادم والعميل وسيمنع فقط هجوم رجل في الوسط. رسائل البريد الإلكتروني محفوفة بالمخاطر للغاية وغير آمنة.
وأفضل أن يكون اسم المستخدم وكلمة المرور المصادقة للوصول إلى المعلومات.
وأنا أحب فكرة الكعكة أكثر أو أقل. يجب أن تشفير المعلومات الكعكة كذلك. يجب عليك أيضا إنشاء الرمز المميز مع الملح والعبارة الرئيسية بالإضافة إلى $ _SERVER [ 'HTTP_USER_AGENT'] للحد من احتمال وقوع هجوم. تخزين المعلومات كما غير حساس كثيرا عن العميل في ملف تعريف الارتباط للاستخدام التحقق.
ويمكن تخزين العبارة الرئيسية في ملف تعريف الارتباط لسهولة الاستخدام ولكن نأخذ في الاعتبار أن أيضا يمكن أن تكون مسروقة الكعكة = (.
والسماح أفضل عميل اكتب العبارة الرئيسية التي قدمها، والتي يتم تخزينها أيضا في قاعدة البيانات مع بياناته.
وأو مفتاح يمكن استخدامها في حالة يستخدم الشخص آلة المختلفة التي تختلف في $ _SERVER [ 'HTTP_USER_AGENT'] المعلمات أو ببساطة يفتقد ملفات تعريف الارتباط. لذلك الكعكة يمكن نقلها أو تعيين.
وأيضا التأكد من أن يتم تشفير بيانات حساسة في قاعدة البيانات. أنت لا تعرف أبدا؛)
وأنت تدرك أنه إذا كان أي القراصنة الحصول على قاعدة البيانات الخاصة بك على الكثير من المعلومات بمحض يمكن أن تعطى بحرية؟
وبعد ذلك أود أن أقول إن هذا ليس سيئا كما فكرة. أنا لن تستخدم MD5 أو SHA1 لأنها ليست آمنة جدا للتجزئة. ويمكن "فك" (وأنا أعلم أنه لا التشفير) بسهولة تامة.
وإلا فإنني ربما استخدام المعلومات الثانية التي لن يتم إرسالها عن طريق البريد الإلكتروني نوع من كلمة مرور. والسبب بسيط جدا، إذا كان شخص الحصول على الوصول إلى البريد الإلكتروني للمستخدم (من السهل جدا مع هوتميل إذا كنت لا تقتل جلسة العمل الخاصة بك) وقال انه سيكون لديك الوصول إلى أي معلومات قد ترسل للمستخدم.
لاحظ أن HTTPS وآمن والبيانات سرداب المرسلة من موقع الويب الخاص بك إلى المستخدم النهائي. أي شيء آخر، اعتبر بمثابة تونيل آمن. لا شيء أكثر nothign أقل.
وحسب ما فهمت من فكرتك، من الناحية النظرية شخص ما يمكن أن اكتب في سلسلة 40 شخصية عشوائية أو MD5 التجزئة والحصول على شخص إلسس التفاصيل. في حين أن هذا قد يكون من المستبعد جدا فإنه يحتاج فقط ليحدث مرة واحدة.
وربما يكون soloution الأفضل أن ترسل للمستخدم عربون ثم نطلب منهم أن يدخل بعض التفاصيل، مثل الاسم والرمز البريدي ورقم الضمان الاجتماعي أو مزيج من هذه.
