Sessions: كيف ستبدو الغوريلا / الجلسات v2؟

أنا أتفق مع كل هذا إلى حد كبير.

عظيم. من المحتمل أيضًا أن أبسط gorilla / securecookie كجزء من هذا: نمت العناصر الداخلية بمرور الوقت ، والانتقال من نهج AES-CTR + MAC الحالي إلى HMAC-SHA-512/256 أو ChaCha20 + Poly1305 (https: // godoc.org/golang.org/x/crypto/chacha20poly1305) وبالتالي تبسيط التشفير.

ملف تعريف الارتباط الآمن هو خلاف ذلك lib صغير ؛ أعتقد أنه كان من الخطأ تطوير واجهة الخطأ بالطريقة التي فعلناها ، ولكن للأسف.

1+ لكل هؤلاء تقريبًا.

ربما تكون قد فكرت في هذا بالفعل ، ولكن أحد الأشياء التي تعلمتها من إنشاء SCS هو أنه على الرغم من أن استخدام JSON للتشفير الافتراضي أمر منطقي من وجهة نظر الأداء ، فإنه من المحتمل أن يجعل الأمور أكثر تعقيدًا للمستخدمين (بافتراض map[interface{}]interface{} لا يزال يستخدم

على سبيل المثال ، استرداد كائن time.Time تم تخزينه مسبقًا. باستخدام ترميز gob ، يمكن للمستخدم فقط استرداد قيمة interface{} وتأكيدها على time.Time . إنها بسيطة ومباشرة إلى حد ما. باستخدام ترميز JSON الأساسي ، يحتاج المستخدم إلى معرفة كتابة تأكيد قيمة interface{} لسلسلة ثم استدعاء time.Parse(time.RFC3339, ...) لإعادتها إلى كائن time.Time .

وبالمثل ، فإن التعامل مع الأعداد الصحيحة والعائمة و json.Number يمثل بعض الألم.

يمكنك استخدام مساعدين (كما فعلت في SCS) ، أو ربما يكون هناك شيء ذكي يمكن القيام به باستخدام أداة إلغاء تنظيم JSON المخصصة. في كلتا الحالتين ، سيكون من الجيد الاستمرار في الاستخدام ليس أكثر صعوبة مما هو عليه مع ترميز gob.

زوجان من الاقتراحات الأخرى.

سيكون من الجيد أن يتم دعم المهلات المطلقة والخاملة (بما يتماشى مع توصيات OWASP ).

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

شكرا على المدخلات alexedwards -

• كان gob (هو!) الأكثر توافقًا ، لذلك يمكنني الاحتفاظ به ، وجعل التغيير بينهما أسهل قليلاً.

سيكون من الجيد أن يتم دعم المهلات المطلقة والخاملة (بما يتماشى مع توصيات OWASP).

نعم موافق. قد يكون بعض opts.MaxAge و opts.IdleTimeout مفيدًا. سأحتاج إلى التفكير في كيفية توظيف ذلك دون تنفيذ Set-Cookie على كل إجابة أيضًا.

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

موافق - طريقة Refresh ستكون مفيدة هنا ، أو وسيطة لـ Save تحقق نفس التأثير (تصدر معرّف جديد).

https://github.com/gorilla/securecookie/issues/43 يتتبع "الإصدار 2" من ملف تعريف الارتباط الآمن الذي سيعزز بعض هذا العمل

هذا يبدو رائعا. سؤال واحد: هل فكرت / ما هي المفاضلات بين وضع المتاجر المضمنة مع واردات غير stdlib (ملف تعريف الارتباط ، boltdb) في عبوات منفصلة؟

شكرا لكم على كل ما تبذلونه من العمل!

ccahoon ستكون كل المتاجر في حزم منفصلة ("حزم فرعية") بحيث إذا لم تستخدم BoltDB ، فلن يتم استيرادها.

توجد بالفعل خلفيات Redis و MySQL و Postgres ، ومتجر Redis موجود بالفعل
إلى حد ما مصقول. جميع متاجر الطرف الثالث مرتبطة في README.
في الخميس ، 23 مارس 2017 الساعة 4:47 مساءً ، كتب كايل تيري [email protected] :

سيكون دعم Redis وقاعدة البيانات (sql) رائعًا أيضًا. إذا كنت تقوم بتشغيل n
مثيلات التطبيق التي تستخدم الغوريلا / الجلسات التي تحتاج إلى أن تكون قادرًا على ذلك
اجعل جلساتك مركزية في جولة روبن.

-
أنت تتلقى هذا لأنه تم تعيينك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/gorilla/sessions/issues/105#issuecomment-288893992 ،
أو كتم الخيط
https://github.com/notifications/unsubscribe-auth/AABIcDfaPALfkjOw5FzdDoM_MHs9RbCYks5rowSIgaJpZM4LwM5f
.

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

أي جدول زمني على هذا؟

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

طريقة لتعطيل ذاكرة التخزين المؤقت في الذاكرة ستكون رائعة.

هل يمكنك مشاركة المزيد من التفاصيل هنا؟ يجب أن تعيش ذاكرة التخزين المؤقت لشخص واحد فقط
طلب؛ خلاف ذلك لا يتم تخزين الجلسات في الذاكرة عبر الطلبات.
يوم الإثنين 18 ديسمبر 2017 الساعة 5:16 صباحًا Romain Menke [email protected]
كتب:

طريقة لتعطيل ذاكرة التخزين المؤقت في الذاكرة ستكون رائعة. هذه الحزمة
غير قابل للاستخدام في التطبيقات التي تعمل على حالات متعددة.

-
أنت تتلقى هذا لأنه تم تعيينك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/gorilla/sessions/issues/105#issuecomment-352422398 ،
أو كتم الخيط
https://github.com/notifications/unsubscribe-auth/AABIcETDijyILlKONBJDuBlr6REcQgK6ks5tBmWTgaJpZM4LwM5f
.

elithrar My bad ، كنت تبحث في عدد كبير جدًا من الحزم التي تستخدم ذاكرة تخزين مؤقت في الذاكرة يتم مشاركتها عبر الطلبات. بالنظر إلى الكود المصدري ، لم يتضح على الفور ما إذا كان السجل معزولًا في طلب واحد. تشك للإشارة إلى هذا!

هل لا يزال Dep 1.0 مانعًا؟ وفقًا للحالة في الملف التمهيدي ، يعد dep آمنًا لاستخدام الإنتاج: https://github.com/golang/dep#current -status
وهي ملفات البيان والقفل مستقرة. انظر: https://github.com/golang/dep/wiki/Roadmap#timeline

ما أفهمه هو أنه إذا بدأت الغوريلا / الجلسات في استخدام dep ، فلا ينبغي أن تتأثر الحزم النهائية. انظر: https://github.com/golang/dep/blob/master/docs/FAQ.md#my -dependers-dont-use-dep-yet-what-should-i-do

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

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

لم يكن هذا هو الوضع الراهن ، وعدم وجود خيار في سلسلة الأدوات
هي نقطة الألم للمستخدمين العاديين.

يُفضل بشدة وجود dep في سلسلة أدوات Go قبل استخدامها في
كسر API هنا.

قد نفعل ذلك في وقت أبكر من ذلك ، ولكن ليس من دون دراسة متأنية.

سيكون الخيار الآخر هو إنشاء حزمة / ريبو جديدة في حالة الاحتفاظ
التوافق مع الإصدارات السابقة أمر بالغ الأهمية.

وينتهي الأمر بجذب المستخدمين القدامى والتسبب في الكثير من الارتباك. أنا لا
رأيت أن تعمل بشكل جيد حتى الآن.
يوم الأربعاء 10 يناير 2018 الساعة 11:19 مساءً كتب Dale Hui [email protected] :

هل لا يزال Dep 1.0 مانعًا؟ حسب الحالة في الملف التمهيدي ، القسم هو
آمن للاستخدام في الإنتاج: https://github.com/golang/dep#current -status
وهي ملفات البيان والقفل مستقرة. نرى:
https://github.com/golang/dep/wiki/Roadmap#timeline

ما أفهمه هو أنه إذا بدأت الغوريلا / الجلسات باستخدام dep ، downstream
لا ينبغي أن تتأثر الحزم. نرى:
https://github.com/golang/dep/blob/master/docs/FAQ.md#my -dependers-dont-use-dep-yet-what-should-i-do

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

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/gorilla/sessions/issues/105#issuecomment-356847518 ،
أو كتم الخيط
https://github.com/notifications/unsubscribe-auth/AABIcO-Q_kwTZCommIiIm02ce7dd2afRks5tJbYWgaJpZM4LwM5f
.

dep ensure -add github.com/gorilla/sessions@^1.0.0 بتثبيت الحزمة بشكل صحيح.
لكن نعم ، أي شخص يستخدم (أو يستخدم) go get سيواجه مشكلة وأعتقد أنه من السابق لأوانه إجبار جميع الحزم النهائية على البدء في استخدام dep .

ما رأيك في إنشاء فرع v2 لبدء كل عمل v2 ، ووضع علامات على الإصدارات الجديدة من فرع v2 ، ومطالبة مستخدمي v2 باستخدام dep ؟ يمكن دمج فرع v2 مرة أخرى في النسخة الرئيسية عندما يكون dep جزءًا من toolchain.

نعم ، هذا خيار فكرت فيه.

سأحتاج أيضًا إلى بدء العمل على Securecookie أولاً ، حيث تعتمد الجلسات
على ملف تعريف الارتباط securecookie ، وأود تحديث هذه المكتبة.

يوم الخميس ، 11 يناير 2018 الساعة 11:45 صباحًا ، كتب Dale Hui [email protected] :

ضمان - إضافة github.com/gorilla/[email protected] يجب تثبيته بشكل صحيح
حزمة.
لكن نعم ، أي شخص استخدم (أو يستخدم) go get سيواجه مشكلة وأنا
أعتقد أنه من السابق لأوانه إجبار جميع الحزم النهائية لبدء الاستخدام
قسم.

ما رأيك في إنشاء فرع v2 لبدء كل عمل v2 ،
وضع علامات على الإصدارات الجديدة خارج فرع v2 ، ومطالبة مستخدمي الإصدار 2 باستخدامها
قسم؟ يمكن دمج فرع v2 مرة أخرى في النسخة الرئيسية عندما يكون القسم جزءًا من
سلسلة الأدوات.

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/gorilla/sessions/issues/105#issuecomment-357039763 ،
أو كتم الخيط
https://github.com/notifications/unsubscribe-auth/AABIcFVJM02Np6zhOehopNPu2dmzUwPkks5tJmTEgaJpZM4LwM5f
.

رائع ، lemme أعرف أين يمكنني المساعدة من خلال وضع علامة على أي مشكلة في sessions أو securecookie

إذا كان لديك أي آراء حول:

• قائمة المثقاب Securecookie v2:
  https://github.com/gorilla/securecookie/issues/43
• كيف ستبدو واجهة برمجة تطبيقات الجلسات المحدثة (اقرأ: ما المشكلات
  نحلها عن طريق تغيير API الحالي؟ هل نحن بحاجة إلى ذلك؟)
• ما إذا كان المتجر يحتاج إلى تغييرات.

هناك عدد قليل من المشكلات التي تم وضع علامة "v2" عليها والتي توفر بعضها
الخلفية / تعليقات المستخدم ، لكني أريد التأكد من حل أي منهما
مشاكل ، أو حل المشاكل القديمة بشكل أفضل ، عن طريق كسر API. كسر ل
من أجل الكسر أقل منطقية ؛)

يوم الخميس ، 11 يناير 2018 الساعة 4:20 مساءً ، كتب Dale Hui [email protected] :

رائع ، lemme أعرف أين يمكنني المساعدة من خلال وضع علامة على أي مشكلة في
جلسات أو ملف تعريف ارتباط الأمان

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/gorilla/sessions/issues/105#issuecomment-357104851 ،
أو كتم الخيط
https://github.com/notifications/unsubscribe-auth/AABIcOppAU5Mj8YyU6US-lRBQ14wgb8oks5tJqVJgaJpZM4LwM5f
.

أعتقد أن معظم التحسينات المدرجة في وصف المشكلة جيدة.
التغييرات التي أجدها مفيدة للغاية (بالترتيب) هي:

1. إثراء واجهة المتجر
   
   
   
   • يجب تجديد وإعادة تصميم واجهة برمجة تطبيقات المتجر. لا ينبغي أن يكون منفذ متجر الجلسة مسؤولاً عن تعيين ملف تعريف ارتباط HTTP في الاستجابة. يجب التعامل مع إدارة ملفات تعريف الارتباط ودورة حياة الجلسة من خلال الحزمة sessions ، وليس بواسطة المتجر.
   
   
   • يجب أن يكون لمخازن الجلسات مصدر قلق واحد فقط وهو استمرار بيانات الجلسة. سيؤدي دفع الوظائف الأساسية (حتى أجزاء منها) إلى المتاجر إلى سلوكيات غير متسقة بين متاجر الطرف الثالث ويجعل من الصعب تغيير الوظائف الأساسية في المستقبل.
   
   
   • إن تبسيط طرق المتلقي Store لعدم استخدام http.Request و http.ResponseWriter سيكون تغييرًا جذريًا.
   
   
2. طلب دعم. سياق (فقط)
   
   
   
   • هل سيظل التسجيل / ذاكرة التخزين المؤقت ضروريًا إذا تم استخدام request.Context ؟
   
   
   • تتمثل الطريقة الأنظف لجلسات التخزين المؤقت في تنفيذ ذاكرة التخزين المؤقت كمخزن جلسة "يلتف" مخزن جلسة موجود. ثم يمكن للمطور الاختيار بين تطبيقات التخزين المؤقت المختلفة أو استخدام طبقات تخزين مؤقت متعددة. على سبيل المثال ، ذاكرة التخزين المؤقت أثناء المعالجة ، و memcached ، و SQL store
   
   
3. برمجية وسيطة خارج الصندوق تتيح الجلسة
   
   
   
   • لدي أيضًا برنامج وسيط يحفظ الجلسة التي من شأنها معالجة هذا التحسين: "تحسين تجربة المستخدم حول Save (نسيان حفظ الأشياء السيئة ، وهو أمر شائع بما فيه الكفاية!)
   
   
   • والمساعدة في تحسين "إثراء واجهة المتجر"
   
   
4. واجهة تشفير محسنة
   
   
   
   • أنا معجب بوجود إعدادات افتراضية آمنة ولكن السماح للمطور بتخصيص الأمان لحالة استخدامهم. من الطرق الجيدة لفعل ذلك كشف طرد منفصل "غير آمن" أو "خطر". مستوحى من https://golang.org/pkg/unsafe/ و https://cryptography.io/en/latest/
   
   
5. JSON هو المشفر الافتراضي

فيما يتعلق بـ "جعل الجلسات. القيم أفضل (المحددون ، الحاصلون ، بدلاً من الخريطة)" ، أود الاحتفاظ بخريطة sessions.Values ولكن أيضًا أفضح أدوات الكتابة والإعدادات. قد يكون للمطور طريقته الخاصة في التعامل مع حالات فشل صب النوع.

شكرا لملاحظاتك dhui

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

يوافق على. تحتاج المتاجر إلى معرف الجلسة (للسماح بالبحث) و TTL (للسماح بانتهاء الصلاحية) وحمولة الجلسة نفسها. هناك بعض الطرق هنا - سأحذف context.Context من التواقيع في الوقت الحالي لأن ذلك يتطلب مزيدًا من المناقشة.

type Store interface {
    Get(id string) (*Session, error)
    Save(session *Session) error
    Expire(id string) (bool, error)
}

ستحتاج المتاجر إلى الاهتمام بتنظيم *Session إلى التنسيق الصحيح: يمكننا بدلاً من ذلك إرسال id string, exp time.Time, data []byte حيث يتم تنظيم data بالفعل ، لكنني أشعر أن التنظيم ضمن مورد المتجر .

طلب دعم. سياق (فقط)
هل سيظل التسجيل / ذاكرة التخزين المؤقت ضروريًا إذا تم استخدام request.Context؟

لا ، لكن هذا يعود إلى التغيير الأكبر والأكبر. سوف ندعم فقط context.Context في الإصدار 2 لأن gorilla/context لا يتعاون عند استخدامه بجانب request.WithContext نظرًا للطريقة التي يستنسخ بها الطلب.

برمجية وسيطة خارج الصندوق تتيح الجلسة

كيف ستجعلها متاحة؟ في سياق الطلب؟ إذا كان الأمر كذلك ، فإن جلبه من هناك هو نفس مقدار الكود - باستثناء تأكيدات النوع مثل السياق. القيمة هي interface{} - مثل استدعاء sessions.Get(ctx, name) .

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

واجهة تشفير محسنة
أنا معجب بوجود إعدادات افتراضية آمنة ولكن السماح للمطور بتخصيص الأمان لحالة استخدامهم. من الطرق الجيدة لفعل ذلك كشف طرد منفصل "غير آمن" أو "خطر". مستوحى من https://golang.org/pkg/unsafe/ و https://cryptography.io/en/latest/

كنت بحاجة لرؤية حجة مقنعة للغاية لهذا. لا أرى أي حالة استخدام منطقية لسبب احتياج المطور إلى تخصيص أساسيات التشفير لمكتبة الجلسات. لن تحتاج إلى استبدال CSPRNG ، ولن تحتاج إلى تغيير AEAD. سنستخدم HMAC-SHA-512 لوضع المصادقة فقط و XSalsa20-Poly1305 للوضع المشفر (AEAD).

JSON هو المشفر الافتراضي

نعم!

فيما يتعلق بـ "إنشاء الجلسات. القيم بشكل أفضل (المحددون ، المحاضرون ، بدلاً من الخريطة)" ، أود الاحتفاظ بالجلسات. خريطة القيم ولكن أيضًا فضح محاضر الكتابة وضبطها. قد يكون للمطور طريقته الخاصة في التعامل مع حالات فشل صب النوع.

يوافق على!

على الرحب و السعة! شكرا لكونك منفتحًا وتقبلًا للأفكار المختلفة!

ستحتاج المتاجر إلى الاهتمام بتنظيم * الجلسة إلى التنسيق الصحيح: يمكننا بدلاً من ذلك إرسال سلسلة المعرف ، ووقت انتهاء الصلاحية ، والوقت ، والبيانات [] البايت حيث يتم تنظيم البيانات بالفعل ، لكني أشعر أن التنظيم يكون ضمن مورد المتجر.

متفق عليه. أعتقد أن المتجر يجب أن يكون مسؤولاً عن تخزين البيانات حيث قد تكون هناك آليات تخزين أكثر كفاءة للمخزن إلى جانب []byte . سيحتاج Session إلى تصدير جميع الحقول ذات الصلة إلى المتاجر لدعم التنظيم وإلغاء التنظيم.

كيف ستجعلها متاحة؟ في سياق الطلب؟

نعم ، أنا معجب بالبرامج الوسيطة التي تقوم بتعيين Session باستخدام نوع مفتاح سياق غير مُصدر في request.Context() . بهذه الطريقة ، يوجد رمز لوحة مرجل أقل قليلاً للمطور المستهلك.
شيء من هذا القبيل sessions.SessionFromRequest(http.Request) (*Session, error) . يمكننا أيضًا إسقاط error وإنشاء Session جديدًا إذا تم استخدامه بدون البرامج الوسيطة ، ولكن قد يؤدي ذلك إلى أخطاء خفية إذا كانت هناك مكالمات متعددة تستخدم نفس الطلب.

ستحتاج البرامج الوسيطة إلى اختطاف http.ResponseWriter وتأجيل عمليات الكتابة حتى تتمكن من الحفظ.

لست مألوفًا مع واجهة Hijacker ، ولكن يبدو أننا نريد التوافق مع اتصالات HTTP / 2. لست متأكدًا مما إذا كان التفاف ResponseWriter لتعيين ملف تعريف الارتباط بعد استدعاء WriteHeader() هو أفضل مسار.

هناك أيضًا حقيقة أنك قد لا ترغب في التوفير عند كل طلب.

نقطة جيدة فيما يتعلق بالبرامج الوسيطة. يمكن أن يكون لدينا 2 من البرامج الوسيطة:

1. الذي يحفظ ويضبط ملف تعريف الارتباط
2. واحد فقط يتحقق من الجلسة).

كنت بحاجة لرؤية حجة مقنعة للغاية لهذا.

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

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

تم وضع علامة على هذه المشكلة تلقائيًا على أنها قديمة لأنها لم تشهد تحديثًا مؤخرًا. سيتم إغلاقه تلقائيًا في غضون أيام قليلة.

تم وضع علامة على هذه المشكلة تلقائيًا على أنها قديمة لأنها لم تشهد تحديثًا مؤخرًا. سيتم إغلاقه تلقائيًا في غضون أيام قليلة.

هل يجب إعادة فتح هذا؟