كيف يمكنني استخدام Delphi لإنشاء تحدٍ مرئي / استجابة لاستعادة الوصول إلى التطبيق؟

Question

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

يتم تأمين المستخدم من برنامج معين ، ومن أجل الوصول إلى وقت واحد ، أريد:

1. يجب تقديم المستخدم مع عبارة تحدي ، مثل "28394LDJA9281DHQ" أو نوع من القيمة الفريدة بشكل معقول
2. سيقوم المستخدم بالاتصال بموظفي الدعم ويقرأ هذا التحدي (بعد أن قام موظفو الدعم بالتحقق من هويتهم)
3. سيقوم شخص الدعم بكتابة قيمة التحدي هذه في برنامج على نظامه الذي سيولد استجابة ، وهو أمر فريد من نوعه مثل الاستجابة ، مثل "9232KLSDF92SD"
4. أنواع المستخدمين في الاستجابة ويحدد البرنامج ما إذا كانت هذه استجابة صالحة أم لا.
5. إذا كان الأمر كذلك ، فسيتم منح المستخدم الوصول إلى التطبيق 1.

الآن ، كيف أفعل هذا هو سؤالي؟ سيكون لدي تطبيقان ليس لديهم وصول الشبكات إلى بعضها البعض. هل هناك أي وظيفة داخل Windows يمكن أن تساعدني في هذه المهمة؟

أعتقد أنه يمكنني استخدام بعض الوظائف في الداخل cryptoapi, ، لكنني لست متأكدًا من أين أبدأ. أقدر أي مساعدة يمكن أن تقدمها.

Answer 1

أود تنفيذ مصادقة التحدي المستندة إلى MD5.

من ويكيبيديا http://en.wikipedia.org/wiki/cram-md5

بروتوكول

1. التحدي: في مصادقة CRAM-MD5 ، يرسل الخادم أولاً سلسلة تحد إلى العميل.
2. الإجابة: يستجيب العميل باسم المستخدم متبوعًا بحرف الفضاء ثم هضم 16 بايت في تدوين سداسي عشري. Digest هو إخراج HMAC-MD5 مع كلمة مرور المستخدم كمفتاح سري ، والتحدي الأصلي للخادم كرسالة.
3. مقارنة: يستخدم الخادم نفس الطريقة لحساب الاستجابة المتوقعة. إذا كانت الاستجابة المعطاة ومطابقة الاستجابة المتوقعة ، فعندئذ كانت المصادقة ناجحة.

هذا يوفر ثلاثة أنواع مهمة من الأمن.

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

الميزتان المهمينان لهذا البروتوكول اللذين يوفران هذه الفوائد الأمنية الثلاثة هما التجزئة أحادية الاتجاه والتحدي العشوائي الجديد.

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

هام: لديها بعض نقاط الضعف ، وتقييم بعناية كيف يمكن أن تؤثر عليك.

Answer 2

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

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

قد يكون وضعك/سياقك مختلفًا. ربما لن تستخدمه بشكل متكرر كما فعلنا. ولكن هنا بعض الاقتراحات:

1. فكر بعناية في طول ومحتويات الكود: معظم المستخدمين (وموظفي الدعم) يستاءون من كتابة الكثير من الأحرف. العديد من المستخدمين من الطباعة السيئة. النظر في ما إذا كانت سلسلة طويلة وتشمل علامات الترقيم وحساسية الحالة تزدهر بشكل لا مبرر له مقارنة بكمية الأمن المضافة.

2. بعد سنوات من استخدام التحدي اللفظي/تنفيذ الاستجابة ، تركنا في مكانه (باعتباره خريفًا) لكننا أضفنا نظامًا آليًا بسيطًا. لقد اخترنا استخدام FTP بدلاً من نهج ويب أكثر تطوراً بحيث لم يكن لدينا أي برنامج يعمل على خادمنا الداخلي (أو التعامل مع موظفي تكنولوجيا المعلومات لدينا!)

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

يتم توجيه العميل من قبل موظفينا للضغط على مفتاح ساخن يقرأ ملف FTP ، ويصادقه ، ويضع ملف استجابة على الخادم.

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

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

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

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

استخدمنا أدوات FTP Vanilla Indy Plain مع عدم وجود مشكلة.

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

آسف إذا لم يكن أي من هذا مناسبًا لك. آمل أن يساعدك هذا قليلا.