بازگشت

Bcrypt Tool

رمزنگاری

هش و تأیید رمز عبور با Bcrypt در مرورگر

آفلاین داده‌های شما روی مرورگر رمزنگاری
رمز عبور
cost factor (rounds)
10
سریع:
bcrypt hash
در حال محاسبه
0%
تاریخچه (hover برای نمایش)
رمز عبور
bcrypt hash
الگوریتم
cost
salt (22 char)
hash (31 char)
در حال تأیید
0%
زمان تخمینی هر cost
ساختار bcrypt hash
$2b$10$SaltSaltSaltSaltSaltSaHashHashHashHashHashHashHashHashH
نسخه ($2b$)
cost factor
salt (22 char)
hash (31 char)
نکات
cost=10 برای اکثر موارد مناسب است (≈100ms)
bcrypt مقاوم در برابر GPU attack است
حداکثر ۷۲ بایت ورودی پردازش می‌شود
هر بار salt جدید تولید می‌شود — hash یکسان نیست
از Bcrypt برای هش فایل‌های بزرگ استفاده نکنید

Bcrypt چیست و چرا برای هش رمز عبور انتخاب درستی است؟

وقتی یک کاربر در سایت شما ثبت‌نام می‌کند، رمز عبورش را کجا ذخیره می‌کنید؟ اگر پاسخ «به‌صورت متن ساده» یا «با SHA-256» باشد، پایگاه داده‌تان یک بمب ساعتی است. Bcrypt یک الگوریتم هش رمز عبور است که از سال ۱۹۹۹ به‌عنوان استاندارد امنیتی شناخته می‌شود. برخلاف SHA-256 که در یک GPU مدرن با سرعت ۲۲ میلیارد هش در ثانیه اجرا می‌شود، Bcrypt با فاکتور هزینه (Cost Factor) عمداً کند طراحی شده — و همین کندی، امنیت آن است.

چرا SHA-256 برای رمز عبور کافی نیست؟

الگوریتم‌های هش عمومی مثل MD5، SHA-1 و SHA-256 برای سرعت طراحی شده‌اند، نه امنیت رمز عبور. یک کارت گرافیک RTX 4090 می‌تواند کل لیست rockyou.txt با ۱۴ میلیون رمز رایج را در کمتر از یک میلی‌ثانیه در برابر SHA-256 آزمایش کند [web:5]. Bcrypt با cost=12 این سرعت را به حدود ۲۰۰ هش در ثانیه کاهش می‌دهد — یعنی ۱۰ میلیون برابر کندتر [web:5]. این تفاوت بین یک پایگاه داده‌ی آسیب‌پذیر و یک سیستم واقعاً امن است.

آناتومی یک هش Bcrypt

خروجی Bcrypt یک رشته‌ی استاندارد است که تمام اطلاعات لازم برای تأیید رمز عبور را در خود دارد — نیازی به ذخیره‌ی جداگانه‌ی Salt ندارید:

  • Version ($2b$): نسخه‌ی الگوریتم Bcrypt که معمولاً 2a یا 2b است.
  • Cost Factor (12): عدد بین ۴ تا ۳۱ که هر واحد افزایش، زمان محاسبه را دو برابر می‌کند. مقدار ۱۰ تا ۱۲ برای اکثر اپلیکیشن‌ها توصیه می‌شود.
  • Salt (۲۲ کاراکتر): مقدار تصادفی منحصربه‌فرد برای هر رمز عبور که از حملات Rainbow Table جلوگیری می‌کند.
  • Hash (۳۱ کاراکتر): هش واقعی رمز عبور که از ترکیب Salt و رمز عبور تولید شده.

Cost Factor؛ کلید تنظیم امنیت Bcrypt

یکی از مهم‌ترین ویژگی‌های Bcrypt قابلیت تنظیم فاکتور هزینه است. هرچه سخت‌افزار قوی‌تر شود، می‌توانید این عدد را افزایش دهید تا امنیت سیستم حفظ شود. cost=10 حدود ۱۰۰ میلی‌ثانیه، cost=12 حدود ۴۰۰ میلی‌ثانیه و cost=14 حدود ۱.۵ ثانیه زمان می‌برد [web:5]. برای وب‌اپلیکیشن‌های معمولی، cost=12 تعادل خوبی بین تجربه‌ی کاربر و امنیت ایجاد می‌کند.

کاربردهای عملی Bcrypt در توسعه وب

  • ذخیره‌سازی رمز عبور کاربران: استاندارد اصلی برای هش رمز عبور در فریم‌ورک‌هایی مثل Laravel، Django، Spring Security و ASP.NET Core Identity.
  • هش پین‌کد و کد تأیید: برای ذخیره‌ی امن کدهای یک‌بار مصرف یا پین‌های کوتاه که در برابر Brute Force آسیب‌پذیرند.
  • Migration از MD5/SHA به هش امن: اگر پایگاه داده‌ی قدیمی دارید، Bcrypt ابزار مناسب برای ارتقاء امنیت است — در هر ورود موفق، هش قدیمی را با Bcrypt جایگزین کنید.
  • تأیید رمز عبور (Password Verify): بررسی تطابق رمز ورودی با هش ذخیره‌شده بدون نیاز به رمزگشایی.
  • تست امنیت و آموزش: درک نحوه‌ی کار Salt و Cost Factor برای توسعه‌دهندگانی که با مفاهیم امنیت وب آشنا می‌شوند.

Bcrypt در مقایسه با الگوریتم‌های مدرن‌تر

Bcrypt هنوز امن است، اما دیگر پیشرفته‌ترین گزینه نیست [web:1]. Argon2id که برنده‌ی مسابقه‌ی Password Hashing Competition در ۲۰۱۵ شد، توصیه‌ی رسمی OWASP برای پروژه‌های جدید است [web:5]. با این حال برای سیستم‌های موجود که از Bcrypt استفاده می‌کنند، مهاجرت اجباری نیست — Bcrypt در عمل هنوز قابل اعتماد است.

ابزار آنلاین Bcrypt Generator و Verifier

با ابزار Bcrypt Tool می‌توانید مستقیماً در مرورگر رمز عبور خود را هش کنید یا یک رمز را در برابر هش ذخیره‌شده تأیید نمایید. Cost Factor قابل تنظیم است و تمام پردازش‌ها به‌صورت کامل client-side و بدون ارسال داده به سرور انجام می‌شود — ایده‌آل برای تست، یادگیری و دیباگ سیستم‌های احراز هویت.

سوالات متداول

پاسخ سوالات رایج درباره این ابزار

آیا می‌توان هش Bcrypt را رمزگشایی (Decrypt) کرد؟

خیر — Bcrypt یک تابع یک‌طرفه است و رمزگشایی آن از نظر ریاضی ممکن نیست. تنها روش تأیید رمز عبور، هش کردن مجدد ورودی با همان Salt ذخیره‌شده و مقایسه‌ی نتیجه است. هیچ ابزار آنلاینی که ادعای «decrypt کردن Bcrypt» دارد معتبر نیست — آن‌ها در واقع از دیکشنری یا Rainbow Table استفاده می‌کنند.

چرا دو بار هش کردن با Bcrypt ایده‌ی بدی است؟

اگر ابتدا رمز عبور را با SHA-256 هش کنید و بعد نتیجه را به Bcrypt بدهید، به مشکل <strong>کوتاه‌شدن فضای ورودی</strong> برمی‌خورید. Bcrypt ورودی را در ۷۲ بایت قطع می‌کند [web:5]، اما خروجی SHA-256 همیشه ۳۲ بایت است — پس از این محدودیت رد می‌شوید ولی تنوع رمزها را از دست می‌دهید. به‌علاوه، هش SHA-256 بدون Salt تولید می‌شود که ریسک Rainbow Table را در مرحله‌ی اول بالا می‌برد. بهترین رویکرد: مستقیماً رمز را به Bcrypt بدهید.

Cost Factor مناسب برای اپلیکیشن من چقدر است؟

قانون کلی OWASP این است که هش کردن یک رمز عبور باید حداقل ۱۰۰ میلی‌ثانیه روی سرور شما طول بکشد. بر این اساس، cost=10 برای سرورهای سبک، cost=12 برای اکثر وب‌اپلیکیشن‌ها و cost=14 برای سیستم‌های با داده‌های حساس توصیه می‌شود. هر چند سال یک‌بار با سخت‌افزار جدید این عدد را آزمایش و در صورت نیاز افزایش دهید.

آیا Bcrypt برای هش کردن توکن یا API Key هم مناسب است؟

نه — Bcrypt اختصاصاً برای رمز عبور طراحی شده است. توکن‌های API و کلیدهای دسترسی معمولاً رشته‌های طولانی و تصادفی هستند که با SHA-256 یا HMAC-SHA256 هش می‌شوند، چون نیازی به کند بودن ندارند و کاربر آن‌ها را تایپ نمی‌کند. برای توکن‌های JWT هم از HMAC یا امضای نامتقارن استفاده کنید، نه Bcrypt.