ایمیل رمز عبور، برگشت‌پذیری را ثابت می‌کند نه یک طرح ذخیره‌سازی
سرویسی که رمز عبور فعلی شما را ایمیل می‌کند نشان داده است که می‌تواند راز را بازیابی کند، نه اینکه از کدام الگوریتم استفاده می‌کند. بازنشانی‌ها را به‌جای آن حول مجوزدهی طراحی کنید.
سرویسی که رمز عبور فعلی کاربر را ایمیل می‌کند یک چیز را ثابت کرده است: می‌تواند آن راز را در قالبی به دست آورد که بتواند بفرستد. اما ثابت نکرده است که کدام ستون، الگوریتم یا کتابخانه آن را تولید کرده است. این تفاوت مهم است، چون یافته واقعی است و نتیجه‌ای که مردم از آن می‌گیرند معمولاً بیش از حد مشخص است. برگشت‌پذیری در جایی از مسیر، سازوکار است؛ قالب ذخیره‌سازی حدسی این‌گونه نیست.
شواهد را در همین سطح نگه دارید تا بقیه بررسی دقیق بماند.
بازگرداندن راز قدیمی چه چیزی را ثابت می‌کند
یک راستی‌آزمای یک‌طرفه نمی‌تواند رمز عبور اصلی را تولید کند، چون طوری طراحی شده است که برگشت‌ناپذیر باشد. اگر سرویس بتواند رمز عبور را ایمیل کند، در آن لحظه موادی را نگه می‌دارد که رمز عبور از آن بازیابی می‌شود، یا متن ساده را پیش از هش‌کردن رهگیری و ذخیره می‌کند. در هر دو حالت مسیر بازیابی برگشت‌پذیر است و این یک یافته واقعی امنیتی است. اما درباره اینکه همان پایگاه داده برای ستون‌های دیگر از هش پرهزینه استفاده می‌کند چیزی نمی‌گوید.
به حالت میانی هم توجه کنید: یک بلاب رمزگذاری‌شده ذخیره‌شده با کلیدی که در اختیار برنامه است، در عمل برگشت‌پذیر است، هرچند واژه رمزگذاری‌شده در یک گزارش دلگرم‌کننده به نظر برسد.
چرا این یافته طراحی است، نه نقشه ذخیره‌سازی
ایمیل، بازیابی‌پذیری را ثابت می‌کند و طرح دقیق را مشخص نمی‌کند. می‌تواند متن ساده، رمزگذاری قطعی، یک روال پوشانندگی از سوی فروشنده، یا یک مخزن اعتبارنامه جداگانه باشد که فقط برای بازیابی استفاده می‌شود. بخش‌های مختلف یک محصول اغلب از ذخیره‌سازی متفاوتی استفاده می‌کنند. نسبت‌دادن یک الگوریتم بر پایه یک ایمیل، همان نوع ادعایی است که در جلسه بعدی فرو می‌ریزد.
آنچه می‌توانید بگویید محدودتر و سودمندتر است: این مسیر می‌تواند راز را بازیابی کند، پس محصول نمی‌تواند ادعا کند که هیچ اعتبارنامه بازیابی‌پذیری وجود ندارد. هر چیز فراتر از آن به شواهد بهره‌بردار نیاز دارد.
بازنشانی را حول مجوزدهی بسازید
بازنشانی مسئله دیگری را حل می‌کند: اثبات اینکه درخواست‌کننده می‌تواند رمز عبور تازه‌ای برگزیند. راهنمای OWASP در این باره توکن‌ها یا کدهای یک‌بارمصرفِ به‌طور ایمن تولیدشده با انقضای مناسب را توصیف می‌کند و مرحله درخواست را چیزی می‌داند که باید در برابر شمارش و سیل درخواست محافظت شود. درخواست تأییدنشده نباید به‌تنهایی حساب را تغییر دهد. پیش از پذیرش جایگزین، مجوز را اعتبارسنجی کنید و توکن را پس از یک استفاده موفق بی‌مصرف کنید.
کانال ایمیل بخشی از مدل امنیتی است. داشتن نام حساب چیزی را ثابت نمی‌کند و جریان بازنشانی‌ای که فاش می‌کند حساب وجود دارد یا نه، به مهاجم فهرستی برای کار کردن می‌دهد.
آنچه را رمز عبور محافظت می‌کرد باطل کنید
تغییر رمز عبور به‌طور خودکار دسترسی‌ای را که اعطا کرده بود پایان نمی‌دهد. نشست‌های فعال VPN، دستگاه‌های به‌یادسپرده و توکن‌های صادرشده توسط سرور ممکن است هر یک رفتار ابطال خودشان را داشته باشند. آگاهانه تصمیم بگیرید کدام‌یک باید پایان یابد و بررسی کنید که پیاده‌سازی این کار را می‌کند، چون کاربری که فرض می‌کند بازنشانی او را همه‌جا خارج کرده است اغلب اشتباه می‌کند. آن تصمیم را همراه با جریان ثبت کنید.
برای بهره‌برداران: مستند کنید کدام مؤلفه درخواست را بررسی می‌کند، کدام اعتبارنامه را تغییر می‌دهد و نشست‌های مرتبط چگونه مدیریت می‌شوند. برای کاربران: کانال بازیابی مشروع را محافظت کنید و هر پیامی را که رمز عبور را برمی‌گرداند مشکوک بدانید.
ارزیابی دقیق کوتاه است: پیام چه چیزی را ثابت می‌کند، چه چیزی ناشناخته می‌ماند و آیا بازیابی دسترسی را از طریق فرایندی کنترل‌شده جایگزین می‌کند.