bcrypt.net
.net 6
نقل bcrypt.codeplex.com مع الأمان المحسن والإصلاحات المفقودة والميزات ودعم .net الأفضل.
التنزيل باستخدام nuget أو Paket (https://fsprojects.github.io/Paket/)
الحزمة: https://www.nuget.org/packages/BCrypt.Net-Next/
الحزمة الموقعة - https://www.nuget.org/packages/BCrypt.Net-Next.StrongName/
توجد أمثلة مختلفة في مجلد أدوات الاختبار واختبارات الوحدات
أبسط استخدام هو كما يلي ...
لتجزئة كلمة المرور:
يتم عرض مساحات الأسماء ذات نطاق الملف؛ تخيل الأقواس المتعرجة إذا كنت بحاجة إلى ذلك.
Top level namespace
namespace DotNetSix ;
using BCrypt . Net ;
string passwordHash = BCrypt . HashPassword ( "my password" ) ;نظرًا لتسمية المكتبة، إذا كانت مساحة الاسم بعد عبارات الاستخدام، يتغير الاستدعاء عندما يفشل .net في حل التسمية بشكل صحيح، أنصحك بدلاً من إدخال مساحة الاسم بالكامل، أن تستخدم ببساطة الاسم المستعار للاستيراد كما هو موضح أدناه.
using BC = BCrypt . Net . BCrypt ;
namespace DotNetSix ;
string passwordHash = BC . HashPassword ( "my password" ) ;يمكنك أيضًا إجراء الأسماء المستعارة على مستوى CSProj؛ ولن تحتاج إلى إضافة عبارة الاستخدام على الإطلاق
سيسمح لك هذا المثال باستخدام الاسم المستعار BC.HashPassword() في التعليمات البرمجية الخاصة بك
< ItemGroup >
<!-- emits global using BcryptNet = global::BCrypt.Net.BCrypt; -->
< Using Include = " BCrypt.Net.BCrypt " Alias = " BC " />
</ ItemGroup > سيسمح لك هذا الإصدار فقط بالاتصال بـ Verify و HashPassword في قاعدة التعليمات البرمجية الخاصة بك دون أي مرجع آخر.
< ItemGroup >
<!-- emits global using static global::BCrypt.Net.BCrypt; -->
< Using Include = " BCrypt.Net.BCrypt " Static = " True " />
</ ItemGroup >ملحوظة: على الرغم من أن هذه المكتبة تسمح لك بتوفير الملح الخاص بك، إلا أنه من المستحسن للغاية أن تسمح للمكتبة بإنتاج الملح لك. يتم توفير هذه الأساليب للحفاظ على التوافق ولمتطلبات الأنظمة الأساسية الأكثر تقدمًا التي قد تتطلب استخدامها.
للتحقق من كلمة المرور مقابل التجزئة (بافتراض أنك قمت بتخزين التجزئة واستعادتها من التخزين للتحقق):
جميع الملاحظات السابقة حول مساحة الاسم تنطبق هنا أيضًا
BCrypt . Verify ( "my password" , passwordHash ) ;سيؤدي هذا التنفيذ على التجزئة إلى إنشاء ملح تلقائيًا لك مع تعيين عامل العمل (2 ^ عدد الجولات) على 11 (والذي يطابق الإعداد الافتراضي عبر معظم عمليات التنفيذ ويُنظر إليه حاليًا على أنه مستوى جيد من الأمان/المخاطر).
لتوفير الرياضيات، يتم توفير جدول صغير يغطي التكرارات أدناه. الحد الأدنى المسموح به في هذه المكتبة هو 4 للتوافق، والحد الأقصى هو 31 (عند 31 سيكون معالجك يتمنى الموت).
| Cost | Iterations |
|-------|--------------------------|
| 8 | 256 iterations |
| 9 | 512 iterations |
| 10 | 1,024 iterations |
| 11 | 2,048 iterations |
| 12 | 4,096 iterations |
| 13 | 8,192 iterations |
| 14 | 16,384 iterations |
| 15 | 32,768 iterations |
| 16 | 65,536 iterations |
| 17 | 131,072 iterations |
| 18 | 262,144 iterations |
| 19 | 524,288 iterations |
| 20 | 1,048,576 iterations |
| 21 | 2,097,152 iterations |
| 22 | 4,194,304 iterations |
| 23 | 8,388,608 iterations |
| 24 | 16,777,216 iterations |
| 25 | 33,554,432 iterations |
| 26 | 67,108,864 iterations |
| 27 | 134,217,728 iterations |
| 28 | 268,435,456 iterations |
| 29 | 536,870,912 iterations |
| 30 | 1,073,741,824 iterations |
| 31 | 2,147,483,648 iterations |
etc
ومعيارًا بسيطًا يمكنك تشغيله عن طريق إنشاء برنامج وحدة تحكم وإضافة مكتبة BCrypt هذه واستخدام هذا الرمز.
var cost = 16 ;
var timeTarget = 100 ; // Milliseconds
long timeTaken ;
do
{
var sw = Stopwatch . StartNew ( ) ;
BCrypt . HashPassword ( "RwiKnN>9xg3*C)1AZl.)y8f_:GCz,vt3T]PI" , workFactor : cost ) ;
sw . Stop ( ) ;
timeTaken = sw . ElapsedMilliseconds ;
cost -= 1 ;
} while ( ( timeTaken ) >= timeTarget ) ;
Console . WriteLine ( "Appropriate Cost Found: " + ( cost + 1 ) ) ;
Console . ReadLine ( ) ; سيبدأ هذا عند 16 وهو 65,536 iterations ويقلل التكلفة حتى يتم الوصول إلى الوقت المستهدف. الأمر متروك لك فيما تعتبره وقتًا مسموحًا به، ولكن إذا كان أقل من 10، فإنني أنصح بشدة بتركه عند 10 وربما الاستثمار في حزمة خادم أكبر.
الحد الموصى به لكلمة المرور وهو 56 بايت (بما في ذلك بايت الإنهاء الخالي) لـ bcrypt يتعلق بحد 448 بت لمفتاح السمكة المنتفخة؛ لا يتم خلط أي بايتات تتجاوز هذا الحد بشكل كامل في التجزئة، مما يجعل الحد المطلق البالغ 72 بايت لكلمات مرور bcrypt أقل أهمية مع الأخذ في الاعتبار التأثير الفعلي على التجزئة الناتجة بواسطة تلك البايتات.
لقد تعاملت اللغات الأخرى مع هذه المشكلة الملحوظة عن طريق التجزئة المسبقة لعبارة المرور/كلمة المرور لزيادة الإنتروبيا المستخدمة، ويعد صندوق الإسقاط أحد أكثر المقالات العامة حول هذا الموضوع.
يمكنك الاشتراك في التجزئة المحسنة ببساطة باستخدام الكود التالي (أساسًا بادئة استدعاءات الطريقة بـ Enhanced)
var enhancedHashPassword = BCrypt . EnhancedHashPassword ( myPassword ) ;
var validatePassword = BCrypt . EnhancedVerify ( myPassword , enhancedHashPassword ) ;افتراضيًا، تستخدم المكتبة تجزئة SHA384 لعبارة المرور، ثم يتم تمرير المادة التي تم إنشاؤها إلى bcrypt لتكوين التجزئة الخاصة بك عبر روتين bcrypt المعتاد. إذا كنت تريد تحديد إصدار مختلف من SHA، أو ترغب فقط في تعيين الإصدار المستخدم بشكل صريح في التعليمات البرمجية الخاصة بك في حالة تغييره في إصدار رئيسي للمكتبة، فيمكنك القيام بذلك باستخدام التغيير التالي لما ورد أعلاه.
var enhancedHashPassword = BCrypt . EnhancedHashPassword ( myPassword , hashType : HashType . SHA384 ) ;
var validatePassword = BCrypt . EnhancedVerify ( myPassword , enhancedHashPassword , hashType : HashType . SHA384 ) ;لماذا SHA384؟ إنه توازن جيد بين الأداء والأمان والحماية من الاصطدام وهو الإصدار الوحيد الذي لم يكن عرضة لهجمات التمديد https://blog.skullsecurity.org/2012/everything-you-need-to-know-about-hash - طول-تمديد-الهجمات.
هل يجب علي استخدام الانتروبيا المحسنة؟ لن تخسر شيئًا باستخدامه
لماذا أحتاج إلى تغيير نوع SHA؟ بعض المكتبات مثل تجزئة PassLib تستخدم SHA256، لذا فهي في الغالب شيء متوافق. استخدم DropBox SHA512، لذا إذا كنت تعمل في Dropbox فستحتاج إلى التوافق. يعد التحسين في الغالب امتدادًا ملائمًا حيث يمكنك بالفعل إجراء التجزئة المسبقة وتمريرها إلى استدعاءات الطريقة القياسية.
ماذا يفعل؟ نحن نأخذ بايتات utf8 من كلمة المرور الخاصة بك حيث تقوم inputBytes SHA بتجزئةها، وتحويلها إلى base64 (للتوافق مع تطبيقات اللغة الأخرى) ثم استخدام تلك البايتات لإجراء استدعاء bcrypt القياسي.
ستحتاج إلى VS2022 على الأقل مع SDK الحالي https://www.microsoft.com/net/download؛
يمكن إنشاء حزم nuget عن طريق تشغيل buildfornuget.cmd أو
dotnet restore . s rc
dotnet pack . s rc B Crypt.Net --configuration Release يمكنك تشغيل الاختبارات من المجلد الرئيسي عن طريق كتابة dotnet test .srcBCrypt.Net.UnitTests سوف يستغرق تشغيل TestGenerateSaltWithMaxWorkFactor وقتًا طويلاً.
تم تنفيذ منفذ .Net الخاص بـ jBCrypt في لغة C#. يستخدم متغيرًا من جدول المفاتيح الخاص بخوارزمية تشفير السمكة المنتفخة، ويقدم عامل عمل، والذي يسمح لك بتحديد مدى تكلفة وظيفة التجزئة، مما يسمح للخوارزمية بأن تكون "مقاومة للمستقبل".
هذا، لجميع المقاصد والأغراض، منفذ مباشر لـ jBCrypt كتبه داميان ميلر. تتمثل الاختلافات الرئيسية في إضافة بعض طرق الراحة وبعض عمليات إعادة العوملة البسيطة. أسهل طريقة للتحقق من تكافؤ BCrypt.Net مع jBCrypt هي مقارنة اختبارات الوحدة.
للحصول على نظرة عامة حول سبب أهمية BCrypt، راجع كيفية تخزين كلمة المرور بأمان. بشكل عام، إنها خوارزمية تجزئة يمكن تعديلها بمرور الوقت لتتطلب المزيد من طاقة وحدة المعالجة المركزية لإنشاء التجزئة. وهذا، في جوهره، يوفر بعض الحماية ضد قانون مور. أي أنه مع زيادة سرعة أجهزة الكمبيوتر، يمكن تعديل هذه الخوارزمية لتتطلب المزيد من طاقة وحدة المعالجة المركزية. كلما زادت طاقة وحدة المعالجة المركزية المطلوبة لتجزئة كلمة مرور معينة، زاد الوقت الذي يجب أن يستثمره "المتسلل" لكل كلمة مرور. نظرًا لأن "عامل العمل" مضمن في التجزئة الناتجة، فإن التجزئة التي تم إنشاؤها بواسطة هذه الخوارزمية متوافقة مع الأمام/الخلف.
فهو يستخدم نوعًا مختلفًا من جدول المفاتيح الخاص بخوارزمية تشفير Blowfish ويقدم عامل عمل، والذي يسمح لك بتحديد مدى تكلفة وظيفة التجزئة. ولهذا السبب، يمكن لـ BCrypt مواكبة قانون مور. مع زيادة سرعة أجهزة الكمبيوتر، يمكنك زيادة عامل العمل وسيصبح التجزئة أبطأ.
قام نيلز بروفوس وديفيد مازيير بتصميم مخطط crypt() يسمى bcrypt استنادًا إلى السمكة المنتفخة، وقدماه في USENIX في عام 1999.[14]
يبدأ النموذج القابل للطباعة لهذه التجزئات بـ
$2$ – Currently obsolete
$2a$ – The current key used to identify this scheme.
Since a major security flaw was discovered in 2011 in a third-party implementation of the algorithm,
hashes indicated by this string are now ambiguous and might have been generated by the flawed
implementation, or a subsequent fixed, implementation.
The flaw may be triggered by some password strings containing non-ASCII characters, such as specially
crafted password strings.
$2b$ – Used by some recent implementations which include a mitigation to a wraparound problem.
Previous versions of the algorithm have a problem with long passwords. By design, long passwords
are truncated at 72 characters, but there is an 8-bit wraparound problem with certain password
lengths resulting in weak hashes.
$2x$ – Post-2011 bug discovery, old hashes can be renamed to be $2x$ to indicate that they were generated with
the broken algorithm. These hashes are still weak, but at least it's clear which algorithm was used to
generate them.
$2y$ – Post Post-2011 bug discovery, $2y$ may be used to unambiguously use the new, corrected algorithm. On an
implementation suffering from the bug, $2y$ simply won't work. On a newer, fixed implementation, it will
produce the same result as using $2a$.
أولاً وقبل كل شيء، نشأت هذه المكتبة كمنفذ لـ jBCrypt من mindrot ، وبعد ذلك تم ضبط مراجعة bcrypt للمطابقة، وهي في هذه الحالة $2a$ . لقد تم تغيير هذا لأن التعامل مع المراجعة الفردية فقط يسبب مشكلات عبر الأنظمة الأساسية مع التطبيقات التي تم نقلها إلى تغيير مراجعتها للتعامل مع عمليات الترحيل والمشكلات الأخرى.
The original bcrypt code (released in OpenBSD 2.1) identified itself as
$2$. Shortly after release, a bug was fixed and the hash identifier
changed to $2a$. Support for "minor" versions wasn't really
planned, but it was backwards compatible.
Solar Designer wrote a second implementation of bcrypt. This
reimplementation suffered from a flaw dealing with 8 bit characters
and led to the introduction of the 'x' and 'y' flavours. OpenBSD did
not have this problem and supports neither 'x' nor 'y' hash versions.
---
Solar found a bug in their OpenBSD implementation of bcrypt when hashing
long passwords. The length is stored in an unsigned char type, which
will overflow and wrap at 256. Although we consider the existence of
affected hashes very rare, in order to differentiate hashes generated
before and after the fix, we are introducing a new minor 'b'.
OpenBSD 5.5 (coming this spring) will accept and verify 'b' hashes,
although it will still generate 'a' hashes. OpenBSD 5.6 (coming this
fall) will change to generating 'b' hashes by default.
A future release of Solar's bcrypt code should also support 'b'.
لا يوجد فرق بين 2a و2x و2y و2b. كلهم يخرجون نفس النتيجة.
ملاحظات الإصدار موجودة هنا https://github.com/BcryptNet/bcrypt.net/releases
v4.0.3 - إضافة استهداف .net 6؛ ترتيب الأهداف.
v4.0.2 - إضافة استهداف .net 5؛ التفاف إنشاء shaxxx في استخدام للإفراج.
الإصدار 4.0.0 (تغييرات عاجلة) - تم اكتشاف خطأ في Enhanced Hashing يتسبب في عدم إمكانية تشغيل التجزئات التي تم إنشاؤها بين اللغات المختلفة. يوفر الإصدار 4 الإصلاح لهذه المشكلة بالإضافة إلى إضافة متجهات اختبار من PHP وPython لضمان بقاء المشكلة ثابتة في المستقبل. يقوم V4 أيضًا بإزالة خيار 384 القديم الذي جاء قبل إضافة Base64.
الإصدار 3.5.0 - تم اكتشاف خطأ في Enhanced Hashing التي تتسبب في جعل التجزئات التي تم إنشاؤها غير قابلة للتشغيل بين اللغات المختلفة. كجزء من الإصلاح 3.5، يحتوي الإصدار على القدرة على Verify وتم منح HashPassword معلمة v4CompatibleEnhancedEntropy إضافية. يتيح ذلك للمستخدم التحقق من التجزئة المحسنة الخاصة به كالمعتاد؛ ثم أعد التجزئة + المتجر باستخدام V4. هذه الوظيفة مخصصة فقط للسماح بالترحيل وتمت إزالتها في الإصدار 4.
v3.3.3 - الأداء (تقليل الكومة) لـ netcore وإزالة regex https://github.com/BcryptNet/bcrypt.net/releases/tag/3.3.0
v2.1.3 -
v2.1.2 -
PasswordNeedsReshash إلى PasswordNeedsRehashv2.1.1 -
الإصدار 2.1.0 -
PasswordNeedsReshash(string hash, int newMinimumWorkLoad) كطريقة مساعدة للمطورين لاستخدامها عند تسجيل دخول مستخدم لزيادة أعباء العمل القديمةValidateAndReplacePassword للسماح بالتحقق من صحة كلمة المرور المضمنة واستبدالها. يطرح BcryptAuthenticationException في حالة فشل المصادقة.الإصدار 2.0.1 -
الإصدار 2.0.0 -
إصدار جديد معبأ لغالبية .net ويحتوي على عناصر آمنة لتقليل مخاطر هجمات التوقيت https://en.wikipedia.org/wiki/Timing_attack / https://cryptocoding.net/index.php/Coding_rules#Compare_secret_strings_in_constant_time من الناحية الفنية، فإن تفاصيل تنفيذ BCrypt تخفف نظريًا من هجمات التوقيت. لكن وظيفة التحقق الرسمية من Bcrypt.net كانت عرضة لهجمات التوقيت حيث عادت بمجرد العثور على بايت غير مطابق في مقارنة التجزئة.
