hashcat چیست و چه زمانی کاربرد دارد؟
hashcat ابزاری برای بازیابی و ارزیابی گذرواژه از روی داده هش در محیط مجاز است. کاربرد معمول آن برای مدیر امنیت، سنجش مقاومت سیاست گذرواژه یا بازیابی یک داده متعلق به خود سازمان در چارچوب مشخص است. این ابزار گذرواژه را از داخل هش «بیرون نمی‌کشد». برای مجموعه‌ای از نامزدها محاسبات لازم را انجام می‌دهد و نتیجه را با مقدار هدف مقایسه می‌کند. درک این تفاوت ضروری است: هش، رمزگذاری قابل برگشت با یک کلید نیست. موفقیت آزمایش به انتخاب نامزدها، الگوریتم ذخیره‌سازی، پارامترهای آن و منابع محاسباتی وابسته است.
این راهنما بر فهم نتیجه و طراحی آزمایش دفاعی با داده ساختگی تمرکز دارد. داشتن یک فایل هش به خودی خود مجوز بررسی حساب‌های دیگران نیست. برای کار سازمانی، مالک داده، محدوده حساب‌ها، مدت آزمایش و نحوه نگهداری نتیجه باید مشخص باشد. خروجی ممکن است شامل گذرواژه قابل استفاده باشد و از این نظر حساس‌تر از یک گزارش عادی امنیتی است. بهتر است آموزش را با هش‌هایی آغاز کنید که خودتان از عبارت‌های آزمایشی ساخته‌اید یا مثال رسمی پروژه هستند. هیچ نیازی نیست برای فهم ابزار، اطلاعات واقعی کاربران وارد محیط یادگیری شود.
تفاوت هش، salt و الگوریتم ذخیره گذرواژه
یک تابع هش، داده ورودی را به خروجی با ساختار مشخص تبدیل می‌کند. برای یک ورودی و پارامترهای یکسان، نتیجه تکرارپذیر است. همین ویژگی امکان مقایسه را فراهم می‌کند، ولی به معنای وجود روش عمومی برای معکوس کردن تابع نیست. در ذخیره‌سازی گذرواژه، طراحی مناسب باید هزینه آزمودن هر حدس را بالا ببرد. استفاده از تابع سریع عمومی بدون سازوکار مناسب گذرواژه، می‌تواند بررسی تعداد زیادی حدس را ارزان کند. بنابراین نتیجه یک آزمایش فقط درباره «انتخاب کاربران» نیست؛ درباره طراحی ذخیره‌سازی سامانه نیز اطلاعات می‌دهد.
Salt مقدار جداگانه‌ای است که برای جلوگیری از یکسان شدن نتیجه گذرواژه‌های مشابه و کاهش امکان استفاده مجدد از محاسبات به کار می‌رود. Salt معمولاً راز نیست و با اطلاعات لازم برای راستی‌آزمایی نگهداری می‌شود. اشتباه رایج این است که وجود آن را معادل قوی بودن گذرواژه بدانیم. اگر عبارت انتخابی بسیار قابل حدس باشد، همچنان می‌توان همان حدس را با salt مربوط محاسبه کرد. در مقابل، الگوریتم‌های مناسب گذرواژه و تنظیم هزینه، هر تلاش را پرهزینه‌تر می‌کنند. این مفاهیم باید در گزارش جدا شوند تا مشکل سیاست کاربر با مشکل طراحی سامانه مخلوط نشود.
چرا تشخیص قالب اهمیت دارد؟
پیش از هر آزمایش باید بدانید داده با چه الگوریتم و چه قالبی تولید شده است. طول ظاهری رشته کافی نیست؛ چندین قالب ممکن است شباهت داشته باشند. اطلاعات زمینه‌ای از برنامه تولیدکننده، پیکربندی و مستندات آن معتبرتر از حدس زدن صرف بر اساس شکل رشته است. انتخاب حالت نادرست می‌تواند خطای قالب ایجاد کند یا آزمایشی بی‌معنا بسازد. مستندات مثال‌های رسمی hashcat برای مقایسه ساختار ورودی مفید است، اما مثال باید با نسخه نصب‌شده سازگار باشد. شماره حالت‌ها و جزئیات قالب را از راهنمای همان نسخه بخوانید، نه از یک تصویر قدیمی اینترنتی.
برای آموزش، یک نمونه با نتیجه شناخته‌شده انتخاب کنید. عبارت آزمایشی، روش تولید هش و پارامترها را در یادداشت آزمایش ثبت کنید. نخست مطمئن شوید ابزار می‌تواند این نمونه کنترل‌شده را شناسایی کند؛ سپس متغیرها را یکی‌یکی تغییر دهید. اگر نمونه ساده جواب ندهد، آزمودن داده بزرگ‌تر فقط زمان مصرف می‌کند. خطاهایی مثل فاصله اضافی، پایان خط نامناسب، کپی ناقص یا تبدیل اشتباه داده دودویی به متن می‌توانند عامل شکست باشند. از نسخه اصلی فایل محافظت کنید و پاک‌سازی را روی کپی انجام دهید تا بتوانید تغییرات را بررسی و تکرار کنید.
طراحی یک آزمایش آموزشی محدود
یک مجموعه کوچک از عبارت‌های ساختگی با ویژگی‌های متفاوت آماده کنید: چند عبارت کوتاه، چند عبارت طولانی‌تر و چند مقدار تصادفی که در فهرست آزمایشی شما وجود ندارند. هدف این تمرین، شکستن رمزهای ناشناخته نیست؛ هدف مشاهده رابطه میان فضای نامزدها و نتیجه است. اگر نامزد درست اصلاً در مجموعه بررسی نباشد، منابع سریع‌تر آن را جادویی تولید نمی‌کنند. برای هر مرحله، تعداد نامزدها و مدت مجاز را محدود نگه دارید. نتیجه را همراه با توضیح شرایط بنویسید تا تفاوت «پیدا نشد» و «امن بودن اثبات شد» روشن بماند.
در مرحله بعد می‌توانید همان داده آموزشی را با الگوریتم یا پارامتر هزینه متفاوت مقایسه کنید. متغیرهای دیگر را ثابت نگه دارید: دستگاه، نسخه برنامه و مجموعه نامزدها. این مقایسه نشان می‌دهد چرا سرعت اعلام‌شده برای یک الگوریتم را نمی‌توان به همه انواع ذخیره‌سازی تعمیم داد. گزارش نتیجه باید شامل روش اندازه‌گیری باشد، نه فقط یک عدد بزرگ. حتی در آزمایش کوچک نیز زمان آماده‌سازی، بار هم‌زمان سیستم و وضعیت حرارتی می‌توانند اثر بگذارند. هدف، یادگیری روند و محدودیت‌هاست؛ به دست آوردن رتبه در یک جدول سرعت، مسئله متفاوتی است.
نقش پردازنده گرافیکی و محدودیت سخت‌افزار
بعضی محاسبات هش قابلیت اجرای موازی زیادی دارند و پردازنده گرافیکی می‌تواند در آن‌ها مؤثر باشد. میزان سود به الگوریتم، حافظه مورد نیاز، درایور و پیاده‌سازی وابسته است. بنابراین جمله «هر GPU از هر CPU سریع‌تر است» دقیق نیست. پیش از خرید یا تخصیص سخت‌افزار، یک نمونه نماینده از کار مجاز خود را اندازه‌گیری کنید. سرعت آزمایش کوتاه نیز ممکن است با اجرای طولانی فرق کند، چون دما و محدودیت توان تغییر می‌کنند. عددی که بدون مشخصات الگوریتم و شرایط سیستم ارائه شود، برای مقایسه حرفه‌ای کافی نیست.
در ماشین مشترک یا لپ‌تاپ، آزمایش طولانی ممکن است کارهای دیگر را کند کند. زمان‌بندی و محدودیت مصرف را مطابق نیاز محیط انتخاب کنید و از نادیده گرفتن هشدارهای سخت‌افزاری خودداری کنید. اگر ابزار دستگاه را نمی‌بیند، ابتدا سازگاری درایور و محیط اجرا را بررسی کنید. نصب تصادفی چند بسته مختلف معمولاً تشخیص را سخت‌تر می‌کند. در ماشین مجازی نیز دسترسی واقعی به شتاب‌دهنده با وجود نام کارت در میزبان یکی نیست. برای آزمایش آموزشی، کار با حجم کوچک و نتیجه قابل تکرار از شروع با سنگین‌ترین بار ممکن مفیدتر است.
خواندن وضعیت اجرا و معنی پایان آزمایش
در هنگام اجرا باید بدانید چه مقدار کار انجام شده و آیا آزمایش به پایان طبیعی رسیده است. پایان یافتن مجموعه نامزدها به معنی یافتن همه گذرواژه‌ها نیست؛ ممکن است هیچ تطبیقی پیدا نشده باشد. از طرف دیگر، پیدا شدن یک نمونه آزمایشی نشان می‌دهد همان عبارت در محدوده جست‌وجوی شما قرار داشته است. نتیجه را با تعداد داده‌های ورودی، موارد قابل پردازش و موارد بازیابی‌شده گزارش کنید. اگر بخشی از ورودی به دلیل قالب اشتباه رد شده، نباید آن بخش را در گروه «بررسی شد و پیدا نشد» قرار داد.
تخمین زمان باقی‌مانده نیز قطعی نیست. تغییر سرعت، نوع کار و بار سیستم می‌تواند آن را جابه‌جا کند. برای ارزیابی سیاست گذرواژه، بهتر است بودجه زمانی از قبل مشخص باشد و نتیجه در همان محدوده تفسیر شود. مثال «در این دستگاه و با این روش، در مدت تعیین‌شده این تعداد نمونه پیدا شد» از ادعای کلی «این رمزها امن‌اند» دقیق‌تر است. اگر آزمایش متوقف شده، علت توقف را ثبت کنید. توقف به دلیل خطای درایور، قطع برق یا تمام شدن زمان، سه وضعیت متفاوت‌اند و نتیجه‌گیری یکسانی ندارند.
فایل نتیجه و ادامه دادن جلسه
hashcat می‌تواند اطلاعات لازم برای حفظ نتیجه‌های بازیابی‌شده و ادامه برخی کارهای متوقف‌شده را نگهداری کند. این داده‌ها با فایل‌های موقت بی‌اهمیت یکسان نیستند. مستندات رسمی میان فایل نتیجه موسوم به potfile و وضعیت بازیابی جلسه تفاوت می‌گذارند. محل نگهداری و رفتار دقیق را در نسخه مورد استفاده بررسی کنید. پاک کردن پوشه داده برای «تمیز کردن سیستم» ممکن است نتیجه‌های قبلی یا امکان ادامه را از بین ببرد. از سوی دیگر، نگهداری نامحدود همین داده‌ها می‌تواند خطر افشای گذرواژه ایجاد کند؛ باید سیاست مشخصی برای دسترسی و حذف وجود داشته باشد.
برای ادامه یک آزمایش، فایل‌های ورودی و مسیرهای مرتبط را بی‌دلیل تغییر ندهید. اطلاعات وضعیت به شرایط کار قبلی وابسته است و حذف واژه‌نامه یا تغییر ورودی ممکن است ادامه را مختل کند. در یک تمرین کوچک، توقف و ادامه را پیش از اجرای طولانی امتحان کنید. همچنین پیشرفت نمایش‌داده‌شده و نقطه‌ای که واقعاً برای بازیابی ذخیره شده ممکن است یکسان نباشند. این تفاوت توضیح می‌دهد چرا پس از توقف ناگهانی، بخشی از کار دوباره انجام می‌شود. در گزارش عملیاتی، نتیجه نهایی را از خروجی معتبر بخوانید و بر اساس تصویری از میانه اجرا تصمیم نگیرید.
چگونه نتیجه را به بهبود امنیت تبدیل کنیم؟
هدف ارزیابی مجاز، سرزنش کاربران نیست. اگر نمونه‌های بسیاری بر پایه الگوی قابل حدس ساخته شده‌اند، سیاست انتخاب و تجربه کاربری را بررسی کنید. اجبارهای ظاهری ممکن است کاربران را به تغییرات قابل پیش‌بینی سوق دهند. گزارش خوب باید اقدام مشخص پیشنهاد دهد: بهبود روش ذخیره‌سازی، افزایش هزینه مناسب الگوریتم، استفاده از مدیر گذرواژه، جلوگیری از استفاده مجدد یا تقویت احراز هویت. هر اقدام باید به یافته مربوط باشد. اضافه کردن توصیه‌های عمومی بدون ارتباط با آزمایش، ارزش تصمیم‌گیری گزارش را کم می‌کند.
اگر در یک ارزیابی واقعی مجاز، عبارتی بازیابی شد، آن را در گزارش عمومی یا تیکت با دسترسی گسترده ننویسید. برای اثبات نتیجه می‌توان از شناسه مستعار و شواهد محدود استفاده کرد. مسئول مجاز باید بداند چه حسابی نیاز به اقدام دارد، ولی همه خوانندگان گزارش نیازی به دیدن متن گذرواژه ندارند. فرایند تغییر رمز و بررسی استفاده مجدد باید طبق رویه سازمان انجام شود. همچنین پاک کردن خروجی نباید تنها به فایل اصلی محدود شود؛ نسخه‌های پشتیبان، گزارش ترمینال و فایل‌های اشتراکی نیز ممکن است همان داده را نگه داشته باشند.
اشتباه‌های رایج و حدود تفسیر
یکی از اشتباه‌ها این است که آزمایش آفلاین هش با حمله آنلاین به صفحه ورود یکسان فرض شود. در حالت آنلاین، محدودیت درخواست، قفل حساب و کنترل‌های سرویس اثر دارند؛ در ارزیابی آفلاین، محاسبات روی داده موجود انجام می‌شود. این تفاوت باید هنگام توضیح خطر به مدیران روشن باشد. کنترل نرخ درخواست برای سرویس مهم است، اما ضعف ذخیره‌سازی گذرواژه پس از افشای پایگاه داده را به تنهایی جبران نمی‌کند. برعکس، الگوریتم ذخیره‌سازی مناسب نیز جای حفاظت از حساب و جلوگیری از افشای داده را نمی‌گیرد.
اشتباه دیگر، تعمیم نتیجه یک مجموعه کوچک به تمام سازمان است. اگر فقط داده آموزشی یا نمونه‌ای از یک سامانه بررسی شده، گزارش باید همان محدوده را بیان کند. نبود نتیجه در مدت کوتاه نشانه مفیدی است، اما تضمین امنیت آینده نیست. تغییر منابع محاسباتی، دسترسی به اطلاعات بیشتر و روش‌های متفاوت می‌توانند نتیجه را تغییر دهند. بهترین استفاده از hashcat در کار دفاعی، تولید شواهد قابل تکرار برای اصلاح طراحی و سیاست است. با داده مجاز، محدوده روشن، حفاظت از خروجی و تفسیر دقیق، ابزار از یک نمایش سرعت به بخشی از ارزیابی مسئولانه امنیت تبدیل می‌شود.
