کاربری به پشتیبانی پیام می‌دهد که «رمزتان منقضی شده، باید عوضش کنید» و او رمز جدید را Company@1403 می‌گذارد. سه ماه بعد همان رمز با یک عدد دیگر. اگر این الگو برایتان آشناست، مشکل از کاربر نیست؛ از سیاست رمز عبوری است که شما نوشته‌اید. اجبار به تعویض دورهای رمز، که سال‌ها استاندارد طلایی حساب می‌شد، امروز در سند NIST SP 800-63B صریحاً توصیه نمیشود. دلیلش ساده است: آدم‌ها زیر فشار، رمز را قوی نمی‌کنند، فقط قابل‌حدس‌ترش می‌کنند.
سیاست رمز عبور دورهای چه چیزی را واقعاً خراب می‌کند
وقتی تعویض اجباری هر ۶۰ یا ۹۰ روز اعمال می‌کنید، سه چیز قابل پیش‌بینی اتفاق می‌افتد. اول، الگوی افزایشی: Summer1403! به Summer1403!! تبدیل می‌شود. دوم، چرخش بین دو یا سه رمز قدیمی که کاربر در گوشی یا دفتر یادداشت نگه داشته. سوم، انبوهی از درخواست‌های «فراموشی رمز» که خودش کانال حمله باز می‌کند.
اندازه‌گیری‌ها هم همین را نشان می‌دهد. در تحلیل مجموعه‌های رمز لورفته، بخش قابل توجهی از رمزهای فعال دقیقاً همان رمزهای قدیمی با یک کاراکتر اضافه در انتها بودند. مهاجمی که یک بار رمز قدیمی شما را از یک دیتابیس لورفته به دست آورده، با یک اسکریپت ساده ده‌ها واریانت را امتحان می‌کند. نرخ موفقیتش بالاست، چون خود سیاست شما به او کمک کرده.
نکته‌ای که کمتر گفته می‌شود: تعویض اجباری هزینه‌ی عملیاتی هم دارد. هر بار چرخش رمز در سرویس‌های داخلی یعنی به‌روزرسانی فایل‌های .env، سکرت‌های CI، اتصال‌های دیتابیس و توکن‌های API. اگر این کار نیمه‌کاره انجام شود، رمز قدیمی در جایی باقی می‌ماند و شما فکر می‌کنید عوضش کرده‌اید.
NIST دقیقاً چه می‌گوید
سند SP 800-63B سه توصیه‌ی مشخص دارد که با رویه‌ی رایج بسیاری از پنل‌های ایرانی در تضاد است:
- تعویض دورهای رمز را اجباری نکنید. تعویض فقط وقتی لازم است که شاهدی از نشت وجود داشته باشد.
- طول را به پیچیدگی ترکیبی ترجیح دهید. یک عبارت عبور ۲۰ کاراکتری از
P@ssw0rd!قوی‌تر است. - رمز را در برابر فهرست رمزهای لورفته و پرتکرار چک کنید، نه در برابر یک الگوی ساده‌ی «حرف بزرگ + عدد + نماد».
ترجمه‌ی عملی‌اش این است: به‌جای اینکه هر سه ماه یک مانع جلوی کاربر بگذارید، یک بار در لحظهی ثبتنام جلوی رمز بد را بگیرید. این کار هم ارزان‌تر است و هم مؤثرتر.
جایگزین عملی: چه چیزی را در کد پیاده کنیم
فهرست سیاه رمزهای لورفته
ساده‌ترین پیاده‌سازی، چک کردن رمز ورودی در برابر فهرست‌هایی مثل Have I Been Pwned است. این API با k-anonymity کار می‌کند: شما فقط پنج کاراکتر اول هش SHA-1 رمز را می‌فرستید و بقیه‌ی مقایسه سمت خودتان انجام می‌شود. رمز کامل هرگز از سرور خارج نمیشود.
# نمونه با curl برای تست دستی
echo -n "password123" | sha1sum | cut -c1-5
# خروجی مثلا: 482c8
curl -s https://api.pwnedpasswords.com/range/482C8 | grep -i "بقیه هش"اگر رمز در فهرست بود، ثبتنام را رد کنید و پیام بدهید «این رمز در نشت‌های قبلی دیده شده». کاربر عصبانی نمیشود، چون دلیلش را می‌فهمد.
حداقل طول و حذف قوانین ترکیبی
حداقل ۱۲ کاراکتر بگذارید، حداکثر را روی ۶۴ یا بیشتر ببندید (نه ۱۶؛ محدودیت کوتاه کاربر را به رمزهای کوتاه‌تر هل می‌دهد). اجازه‌ی فاصله و کاراکتر یونیکد را بدهید. و مهمتر: هرگز رمز را با trim() یا نرمال‌سازی یونیکد قبل از هش کردن دستکاری نکنید، وگرنه کاربر با رمز درست هم نمی‌تواند وارد شود.
احراز هویت دو مرحله‌ای به‌جای چرخش رمز
اگر نگران نشت رمز هستید، پاسخ درست TOTP یا کلید سخت‌افزاری است، نه تعویض اجباری. با 2FA، حتی رمز لورفته هم به‌تنهایی کار نمی‌کند. برای دسترسی ادمین سرور، ترکیب کلید عمومی و غیرفعال کردن ورود با رمز را در امنیت SSH؛ از تغییر پورت تا fail2ban و کلید عمومی قدم‌به‌قدم توضیح داده‌ایم.
این‌جا اشتباه می‌کنند
اشتباه رایجی که واقعاً دیده‌ام: تیم سیاست سخت‌گیرانه‌ی رمز را روی پنل کاربران اعمال می‌کند، اما رمز دیتابیس و کلیدهای API را در یک فایل config.php داخل ریشه‌ی وب‌سرور رها می‌کند. نشانه‌اش هم مشخص است؛ در لاگ دسترسی، درخواست‌های GET /config.php یا GET /.env با کد ۲۰۰ ثبت می‌شود. یعنی مهاجم اصلاً سراغ رمز کاربران نمی‌رود. سیاست رمز عبور سخت روی درِ ورودی، وقتی در پشتی باز است، فقط هزینه دارد.
اشتباه دوم: اجبار به تعویض رمز بدون هیچ راهی برای بازیابی امن. نتیجه‌اش این است که کاربران رمز را در چت تیم می‌فرستند. اگر این الگو برایتان آشناست، مدیریت رمز عبور در تیم‌ها؛ چرا اشتراک در چت ممنوع است؟ را بخوانید و یک مدیر رمز واقعی راه بیندازید.
مقایسه‌ی دو رویکرد
| معیار | تعویض اجباری دورهای | طول + چک نشت + 2FA |
|---|---|---|
| اثر واقعی روی امنیت | کم، حتی منفی | بالا |
| بار روی پشتیبانی | زیاد (بازیابی رمز) | کم |
| واکنش کاربر | دور زدن سیاست | پذیرش منطقی |
| هزینه‌ی پیاده‌سازی | تقریباً صفر | یک بار کدنویسی |
اگر مجبورم انتخاب کنم، رویکرد دوم را می‌گیرم. تنها شرطی که اولی را قابل‌دفاع می‌کند این است که رمز واقعاً لو رفته باشد یا حساب دسترسی سطح بالا داشته باشد و شما هنوز 2FA را راه نینداخته‌اید. آن هم یک بار، نه هر ۹۰ روز.
وقتی رمز لو می‌رود، چه کار کنیم
سیاست بدون فرآیند واکنش، نصفه است. مسیر درست این است:
- همه‌ی نشست‌های فعال آن کاربر را باطل کنید، نه فقط رمز را عوض کنید. توکن‌های JWT و sessionهای دیتابیس جداگانه باطل می‌شوند.
- در لاگ ممیزی بگردید که از زمان نشت چه اتفاقی افتاده. اگر لاگ ممیزی ندارید یا دستکاریپذیر است، لاگ ممیزی چیست و چگونه آن را دست‌نخورده نگه داریم؟ نقطه‌ی شروع است.
- کلیدهای API و توکن‌های سرویس را هم بچرخانید. رمز فقط یکی از راه‌های ورود است.
- به کاربر بگویید چه اتفاقی افتاده. پنهان‌کاری باعث می‌شود دفعه‌ی بعد رمز را جای امنی نگه ندارد.
برای دسترسی کارکنان از بیرون، به‌جای باز کردن پورت دیتابیس به اینترنت، از تونل استفاده کنید؛ راهنمای جامع VPN سازمانی برای دسترسی امن کارکنان همین سناریو را پوشش می‌دهد.
چیزهایی که فراموش می‌شوند
هش کردن رمز با MD5 یا SHA-1 خالی هنوز در بعضی پروژه‌های قدیمی دیده می‌شود. اگر دیتابیس شما لو برود، این هش‌ها در چند ساعت با GPU شکسته می‌شوند. Argon2id یا bcrypt با cost مناسب بگذارید و پارامترها را در کد ثابت نکنید تا بعداً قابل افزایش باشند.
محدودیت نرخ هم جدی است. بدون rate limit روی endpoint ورود، فهرست سیاه رمز بیفایده است چون مهاجم می‌تواند هزاران حدس بزند. یک محدودیت ساده مثل ۱۰ تلاش در ۱۵ دقیقه به‌ازای هر IP و هر حساب، بیشتر حملات خودکار را می‌خواباند. اگر ترافیک حمله از حد رد شد، محافظت در برابر DDoS لایه‌ی بعدی است.
و یک نکته‌ی عملیاتی: هر تغییری در سیاست رمز را در مستندات و پایگاه دانش خودتان بنویسید، نه فقط در ایمیل. شش ماه بعد، کسی که باید سیاست را اجرا کند همان مستندات را می‌خواند.
اگر روی سرور اختصاصی یا ابری کار می‌کنید و می‌خواهید لایه‌های احراز هویت و پایش را یکجا و بدون سردرگمی راه بیندازید، خدمات امنیت سرورنت همین مسیر را پوشش می‌دهد. ولی قبل از هر چیز، همان قانون تعویض اجباری را از پنل کاربرانتان بردارید. این تنها تغییری است که امروز می‌توانید اعمال کنید و امنیت را بالا ببرد.
پرسش‌های پرتکرار
آیا تعویض دورهای رمز عبور کاملاً ممنوع است؟
نه ممنوع است، ولی بهعنوان سیاست پیشفرض توصیه نمیشود. NIST از سال ۲۰۱۷ در SP 800-63B گفته تعویض اجباری را فقط در صورت شاهدی از نشت اعمال کنید. اگر سازمان شما الزام رگولاتوری دارد، حداقل بازه را طولانی کنید و همزمان 2FA را اجباری کنید.
حداقل طول رمز عبور چقدر باشد؟
برای حسابهای معمولی ۱۲ کاراکتر و برای حسابهای مدیریتی ۱۶ کاراکتر یا بیشتر. مهمتر از عدد، اجازه دادن به عبارت عبور طولانی و چک کردن رمز در برابر فهرست نشتهاست. محدودیت حداکثر طول را هم زیر ۶۴ کاراکتر نگذارید.
چطور بفهمم رمز کاربرانم لو رفته است؟
با API فهرست رمزهای لورفته در لحظهی ورود یا ثبتنام چک کنید، و در لاگ ممیزی دنبال ورودهای موفق از IP ناشناس بگردید. اگر لاگها را دستکاریپذیر نگه میدارید، این تشخیص تقریباً بیفایده است.
آیا مدیر رمز تیمی جایگزین سیاست رمز عبور است؟
مکمل آن است، نه جایگزین. مدیر رمز جلوی اشتراک رمز در چت را می‌گیرد و چرخش رمز سرویس‌ها را ساده می‌کند، اما تصمیم درباره‌ی طول، 2FA و واکنش به نشت همچنان وظیفه‌ی شماست.
دیدگاه‌ها ۰
هنوز دیدگاهی ثبت نشده؛ اولین نفر باشید!