ساخت پسورد قوی یعنی انتخاب رمزی که هم حدس‌زدنش دشوار باشد و هم فقط برای همان حساب استفاده شود. گذاشتن یک علامت در انتهای نام یا سال تولد کافی نیست. برای حساب‌های هاست، ایمیل و مدیریت سایت، روش نگهداری رمز نیز به اندازهٔ ساخت آن اهمیت دارد.
طول مناسب برای ساخت پسورد قوی
سقف ۱۲ کاراکتر توصیهٔ درستی نیست. در راهنمای NIST SP 800-63B، حداقل رمز برای احراز هویت تک‌عاملی ۱۵ کاراکتر تعیین شده است؛ در فرایند چندعاملی حداقل ۸ کاراکتر مجاز است. این اعداد الزامات همان راهنما هستند، نه تضمین امنیت هر رمز با آن طول.
برای استفادهٔ روزمره، یک رمز تصادفی بلند بسازید و محدودیت واقعی سرویس را رعایت کنید. اگر سامانه رمز بلند را نمی‌پذیرد، آن را خودسرانه به بخشی کوتاه و قابل حدس تبدیل نکنید؛ محدودیت را از پشتیبانی بررسی و عوامل محافظتی دیگر را فعال کنید.
رمز تصادفی یا عبارت عبور؟
برای رمزی که قرار نیست حفظ کنید، مولد داخلی مدیر رمز انتخاب عملی است. برای رمز اصلیِ قابل حفظ، عبارت چندکلمه‌ای با انتخاب واقعاً تصادفی کلمات می‌تواند مناسب باشد. شعر مشهور، جملهٔ شخصیِ منتشرشده یا چند کلمهٔ قابل پیش‌بینی انتخاب تصادفی نیست.
روش برداشتن حروف اول یک جمله، به‌خودی‌خود رمز غیرقابل حدس نمی‌سازد. همچنین رمز نمونهٔ یک مقاله دیگر محرمانه نیست؛ هیچ نمونهٔ منتشرشده‌ای را برای حساب واقعی انتخاب نکنید. ترکیب حروف و اعداد فقط زمانی کمک می‌کند که به الگوی تکراری تبدیل نشده باشد.
مراحل پیشنهادی ساخت و ثبت رمز
- نشانی رسمی همان سرویس را مستقلاً باز کنید.
- در ابزار مدیریت رمز، ورودی جدا با نام سرویس و حساب بسازید.
- یک رمز تازه و یکتا تولید کنید که با محدودیت سرویس سازگار باشد.
- رمز را در محل امن ثبت و سپس در فرم همان حساب ذخیره کنید.
- ورود با رمز جدید و روش بازیابی مجاز را بررسی کنید.
رمز را برای سنجش قدرت در سایت ناشناس وارد نکنید. رتبهٔ «قوی» در یک فرم، بررسی کامل خطر نیست و افشاشدن رمز در جای دیگر را منتفی نمی‌کند. اگر مدیر رمز را عوض می‌کنید، فایل خروجی بدون رمزگذاری را در پوشهٔ عمومی یا هاست باقی نگذارید.
چرا رمز یکتا مهم است؟
فرض کنید رمز یک انجمن قدیمی افشا شود. اگر همان رمز برای ایمیل بازیابی هاست استفاده شده باشد، خطر از همان انجمن فراتر می‌رود. تغییر نام سرویس در انتهای یک رمز مشترک نیز جداسازی مطمئنی ایجاد نمی‌کند؛ هر حساب باید مقدار مستقل داشته باشد.
چه زمانی پسورد را تغییر دهیم؟
اگر رمز افشا شده، در صفحهٔ مشکوک وارد شده یا با فرد غیرمجاز به اشتراک رفته است، تغییر لازم است. تغییر تقویمیِ بی‌دلیل جای این رسیدگی را نمی‌گیرد و ممکن است به الگوهای قابل پیش‌بینی منجر شود. توصیهٔ NIST نیز الزام تغییر دوره‌ای بدون شواهد افشا را رد می‌کند.
پس از رخداد، نشست‌ها و اطلاعات بازیابی را هم بررسی کنید؛ رمز تازه، نشست دزدیده‌شده یا دستگاه آلوده را خودبه‌خود پاک نمی‌کند. احراز هویت چندعاملی و روش مقاوم به فیشینگ در سرویس‌های پشتیبان، لایهٔ دیگری از حفاظت است.
مطالعهٔ مرتبط
بازبینی فنی: ۱۳ آبان ۱۴۰۵. تاریخ انتشار اولیه و نشانی قبلی حفظ شده‌اند.
