security change - SHA512 مقابل Blowfish و Bcrypt




password to (6)

لقد صادفت هذا:

codahale.com/how-to-safely-store-a-password

هل يمكن أن يكون مؤلف هذا المقال خاطئًا؟

أنا أبحث في خوارزميات التجزئة ، ولكن لا يمكن العثور على إجابة.

  • Bcrypt يستخدم السمكة المنتفخة
  • السمكة المنتفخة هي أفضل من MD5
  • س: ولكن هو السمكة المنتفخة أفضل من SHA512؟

شكر..

تحديث:

أريد أن أوضح أنني أفهم الفرق بين التجزئة والتشفير. ما دفعني لطرح السؤال بهذه الطريقة هو هذا المقال ، حيث يشير المؤلف إلى bcrypt كـ "التجزئة التكيفي" https://www.nccgroup.trust/us/about-us/newsroom-and-events/blog/2007/july/enough-with-the-rainbow-tables-what-you-need-to-know-about-secure-password-schemes/

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


السمكة المنتفخة ليست أفضل من MD5 أو SHA512 ، لأنها تخدم أغراضا مختلفة. MD5 و SHA512 هي خوارزميات التجزئة ، Blowfish هو خوارزمية التشفير. اثنين من وظائف التشفير مختلفة تماما.


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

SHA512 هو خوارزمية التجزئة. وهذا يعني أنه (من الناحية النظرية) بمجرد إدخال الإدخال لا يمكنك الحصول على الإدخال الأصلي مرة أخرى.

إنهما شيئان مختلفان ، مصممان لاستخدامهما في مهام مختلفة. لا توجد إجابة "صحيحة" على "blowfish أفضل من SHA512؟" قد تسأل أيضًا "هل التفاح أفضل من حيوان الكنغر؟"

إذا كنت ترغب في قراءة المزيد حول هذا الموضوع ، فإليك بعض الروابط:


يكفي أن نقول ما إذا كانت bcrypt أو SHA-512 (في سياق خوارزمية مناسبة مثل PBKDF2) جيدة بما فيه الكفاية . والجواب هو نعم ، إما خوارزمية آمنة بما فيه الكفاية أن يحدث خرق من خلال عيب التنفيذ ، وليس تحليل الشفرات.

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

على الرغم من أن bcrypt ككل لم يكن لديه الكثير من التمحيص مثل Blowfish نفسه ، إلا أنني أعتقد أن كونه قائمًا على تشفير ذو بنية مفهومة جيدًا يمنحها بعض الأمان المتأصل الذي تفتقر إليه التوثيق المستند إلى هاش. أيضًا ، من الأسهل استخدام وحدات معالجة الرسومات الشائعة كأداة لمهاجمة التجزئات المستندة إلى SHA-2 ؛ نظرًا لمتطلبات الذاكرة ، يتطلب تحسين bcrypt أجهزة أكثر تخصصًا مثل FPGA مع بعض ذاكرة الوصول العشوائي على اللوحة.

ملاحظة: bcrypt عبارة عن خوارزمية تستخدم Blowfish داخليًا. انها ليست خوارزمية التشفير نفسها. يتم استخدامه لتعتيم كلمات المرور بشكل لا رجعة فيه ، مثلما يتم استخدام وظائف هاش للقيام "تجزئة ذات اتجاه واحد".

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

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

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

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

لذا ، مثل خوارزميات التشفير المستندة إلى خوارزميات لا يمكن عكسها ، تنتج bcrypt نتاجًا لا رجعة فيه ، من كلمة المرور ، والملح ، وعامل التكلفة. تكمن قوتها في مقاومة Blowfish لهجمات واضحة للنص العادي ، وهو ما يشبه "أول هجوم ما قبل الصورة" على خوارزمية الملخص. نظرًا لأنه يمكن استخدامه بدلاً من خوارزمية التجزئة لحماية كلمات المرور ، فإن bcrypt يُشار إليه بشكل مربك باسم خوارزمية "hash" نفسها.

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

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

لذا ، فإن توصيتى لـ bcrypt تنبع من الافتراضات 1) أن السمكة المنتفخة لديها مستوى مماثل من التدقيق مثل عائلة SHA-2 من وظائف هاش ، و 2) أن طرق cryptanalytic لـ ciphers تم تطويرها بشكل أفضل من تلك الخاصة بوظائف هاش.


أود أن أوصي بتطبيق crypt القائم على أساس SHA-256 / SHA-512 من Ulrich Drepper.

قمنا بنقل هذه الخوارزميات إلى Java ، ويمكنك العثور على نسخة مرخصة بحرية منها على ftp://ftp.arlut.utexas.edu/java_hashes/ .

لاحظ أن معظم (L) Unices الحديثة تدعم خوارزمية Drepper في ملفاتها / etc / shadow.


ذلك يعتمد على الاحتياجات الخاصة بك. هل تحتاج إلى:

  • الهوية - من يدعي أنه يقدم طلب واجهة برمجة التطبيقات؟
  • التوثيق - هل هم حقا من يقولون انهم؟
  • إذن - هل مسموح لهم بفعل ما يحاولون القيام به؟

أو الثلاثة؟

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

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

إليك وصفًا جيدًا: http://www.srimax.com/index.php/do-you-need-api-keys-api-identity-vs-authorization/





security encryption passwords hash