روابط عمومی شرکت ایدکو (توزیع‌کننده‌ی محصولات کسپرسکی در ایران)؛ اکنون با نزدیک شدن به ربع اول قرن بیست و یکم، همه تقریباً به این مسئله واقفند که پسوردهای کاربری طلاهای دیجیتالی‌اند و محافظت از آنها بُعد کلیدی تضمین امنیت و حریم خصوصی داده‌ها است. با این حال همه شرکت‌ها هم هنوز بدرستی پسوردها را ذخیره نمی‌کنند. دراین مقاله قصد داریم نگاهی داشته باشیم بر نحوه ذخیره نکردنِ پسوردهای کاربری و روش‌های بکاررفته توسط سرویس‌هایی که امنیت را جدی می‌گیرند.
روش اشتباه: ذخیره پسوردها در متن ساده
ساده‌ترین روش، ذخیره پسوردها در پایگاه داده رمزگذاری‌نشده است. وقتی کاربری سعی بر sign in کردن می‌کند، احراز هویت تنها می‌شود بحث هماهنگی بین آنچه آنها در برابر چیزهایی که در پایگاه داده وجود دارد وارد کرده‌اند. اما همیشه این خطر وجود دارد که مهاجمین این پایگاه داده را سرقت کرده باشند- برای مثال با اکسپلویت آسیب‌پذیری در نرم‌افزار پایگاه داده. یا ممکن است کارمندی شرور پسوردی را از روی میز سرقت کرده باشد که از قضا به مزایای دسترسی بالا نیز مجهز است. همچنین اطلاعات محرمانه نشت‌شده یا رهگیری‌شده‌ی کارمند هم ممکن است برای سرقت پسوردها استفاده شود. ساده‌اش کنیم: کلی سناریو در این خصوص وجود دارد اما این را به یاد داشته باشید که داده‌های ذخیره‌شده در فرم باز به معنای واقعی باز هستند و در معرض!
روشِ کمی بهتر: پسوردهای رمزگذاری‌شده
اگر پسوردها در قالب رمزگذاری‌شده ذخیره شوند چه؟ شاید در نگاه اول ایده بدی نباشد اما در عمل ایده جالبی نیست. از اینها گذشته اگر پسوردهای رمزگذاری‌شده را در پایگاه داده ذخیره کنید باید هر بار برای مقایسه آنها با ورودی کاربری رمزگشایی شوند. و این یعنی کلید رمزگذاری جایی همین نزدیکی‌هاست. اگر این چنین باشد این کلید (به همراه پایگاه داده پسورد) می‌تواند براحتی به دست هکرها بیافتد. پس این کل هدف را شکست می‌دهد: مجرمان سایبری قادر خواهند شد این پایگاه داده را به سرعت رمزگشایی کرده و در متن ساده پسوردها را دریافت کنند. بنابراین دوباره برمی‌گردیم سر خانه اول. کریپتوگرارها بین خودشان با جدیت تمام این شوخی را می‌کنند که: رمزگذاری به معنای حل مسئله حریم خصوصی داده نیست. فقط آن را به یک مشکل ذخیره امن رمز تبدیل می‌کند. شما می‌توانید با انواعی از نقشه‌های حیله‌گرانه برخورد کنید که شاید ریسک را کم کند اما در ک امنیت‌بخشیِ تمامِ پسوردها به طور امن امکان‌پذیر نخواهد بود.
روش خوب: ذخیره هش‌های پسورد
بهترین روش این است که اصلاً پسوردها را ذخیره نکنیم. اگر چیزی نداشته باشید کسی می‌تواند آن را بدزدد؟! معلوم است که نه. اما چطور بررسی کنیم آیا کاربری که sign in کرده پسورد درست را زده؟ اینجاست که هش‌ها وارد میدان می‌شوند: الگوریتم‌های ویژه کریپتوگرافیک که هر داده‌ای را به روش قابل‌پیش‌بینی اما برگشت‌ناپذیر در یک رشته بیت جای می‌دهند. اینجا منظور از قابل‌پیش‌بینی این است که داده‌های یکسان همیشه به همان هش واحد تبدیل می‌شوند. و برگشت‌ناپذیر هم یعنی این پروسه تماماً غیرقابل‌ریکاوری است و داده‌های هش‌شده دیگر از حالت هش خارج نخواهند شد. و اگر سرویس آنلاینی این کار را با داده کاربر کند یعنی هم برای اعتبار خودش و هم ذره ذره اطلاعات کاربر اهمیت و ارزش قائل است. وقتی کارر در طول ثبت نام پسوردی می‌سازد، نه خود پسورد بلکه هش آن در پایگاه داده با نام کاربری ذخیره می‌شود. سپس در طول پروسه sign in این هش با هش پسورد واردشده توسط کاربر تطابق داده می‌شود. اگر هماهنگی بین‌شان وجود داشته باشد یعنی پسورد، یکی است. در صورت نشت پایگاه داده این پسوردها نیستند که مهاجمین در اختیار گرفتند بلکه این هش‌ها هستند که به کنترل آنها درآمدند و داده‌های اورجینال از این هش‌ها غیرقابل‌ریکاوری هستند (همان مفهوم برگشت‌ناپذیر. یادتان است؟). البته از لحاظ امنیتی این پیشرفت عظیمی است اما هنوز جای کار دارد: اگر مجرمان سایبری دستشان به هش‌ها برسد شاید شروع به اجرای حمله جستجوی فراگیر بزنند.
روشی حتی بهتر: هش‌های نمک‌سود شده[1]
بعد از رسیدن به پایگاه داده شما، هکرها ممکن است سعی کنند از طریق جستجوی فراگیر دست به استخراج پسوردهای شما بزنند. این یعنی گرفتن ترکیبی از کاراکترها، محاسبه‌ی هش آن و گشتن به دنبال هماهنگی بین همه ورودی‌های داخل پایگاه داده. اگر هیچ هماهنگی پیدا نشد ترکیب دیگری را سرچ خواهند کرد و این منوال ادامه دارد. اگر مچی هم وجود داشته باشد، پسوردی که برای محاسبه هش در پایگاه داده استفاده شده اکنون شناخته‌شده است. بدتر اینکه کرک کردن پسوردهای هش‌شده می‌تواند با اصطلاحاً جداول رنگین‌کمانی[2] به طور قابل‌ملاحظه‌ای تسریع داده شود. جداول رنگین‌کمانی در واقع آرایش‌های اطلاعاتی بزرگی هستند با تابع‌های هش از پیش‌محاسبه‌شدهبرای پسوردهایی که بیشترین ملاقاتی را دارند. در نتیجه سرچ مچ‌ها در پایگاه داده‌های سرقتی راحت می‌شود. و این کار البته خودکار صورت می‌گیرد پس پروسه کرک پسورد هم سریع‌تر و آسان‌تر انجام می‌شود. با این وجود، خبر خوبی هم وجود دارد: محال است بشود همه ترکیب‌های کاراکتر احتمالی را پیشتر محاسبه کرد (یک جدول کامل رنگین‌کمانی برای هر الگوریتم هش فضای دیسکی به پهنای کره زمین می‌خواهد!). حتی برای الگورتیم نه چندان مطمئن MD5، چنین جدول فرضی شامل 340 282 366 920 938 463 463 374 607 431 768 211 456 رکورد می‌شود (می‌دانیم مغزتان سوت کشید!). و برای همین است که بیشتر ترکیب‌های رایج در جداول رنگین‌کمانی جای گرفته‌اند. برای مبارزه با استفاده از جداول رنگین‌کمانی، کریپتوگرافرها به راهکاری رسیدند که از خاصیت دیگر توابع هش استفاده می‌کند: حتی کوچک‌ترین تغییر در متن منبع، نتیجه هش را ورای تشخیص همه عوض می‌کند. پیش از اینکه هش پسورد در پایگاه داده محاسبه و نوشته شود، مجموعه‌ای رندوم از کاراکترها (که به آن نمک یا salt) می‌گوییم به آن اضافه می‌شوند. بدین‌روش، هش‌های پایگاه اطلاعاتی‌شده تا حدی اصلاح می‌شوند که حتی پایه‌ای‌ترین و واضح‌ترین و پرتکرارترین پسوردها مانند 12345678 و password هم نمی‌توانند با جداول رنگین‌کمانی جستجوی فراگیر شوند. ساده‌ترین متغیر از یک salt برای کل پسوردها استفاده می‌کند. اما مقاوم‌ترین آنها در برابر هک نمک جداگانه‌ای برای هر رکورد جداگانه می‌سازد. زیبایی این رویکرد اینجاست که saltها می‌توانند بدون هیچ ریسک اضافی در همان پایگاه داده ذخیره شوند: این را باید دانست که salt کار مهاجم را چندان آسان هم نمی‌کند. برای کرک کردن هش‌ها، مهاجمین هنوز باید جستجوی فراگیر را انجام دهند (و سراغ یک به یک ترکیب‌ها بروند). هر قدر سرویس های آنلاین بیشتری این متود عدم ذخیره پسوردها را اتخاذ کنند، کمتر سرقت‌های انبوه اطلاعات محرمانه کاربر رخ می‌دهد (و به تبع آن کمتر شاهد هک اکانت خواهیم بود).
[1] salted hashes
[2] rainbow tables
منبع: کسپرسکی آنلاین (ایدکو)
کسپرسکی اسم یکی از بزرگترین شرکتهای امنیتی و سازنده آنتی ویروس است که برخی از کاربران اشتباهاً این شرکت و محصولات آنتی ویروس آن را با عناوینی نظیر کسپرسکای،کاسپرسکی، کسپراسکای، کسپراسکای، و یا کاسپراسکای نیز می‌شناسد. همچنین لازم به ذکر است مدیرعامل این شرکت نیز یوجین کسپرسکی نام دارد.
