همه چیزهایی که باید درباره پیاده‌سازی ویژگی بازنشانی رمز عبور بدانید

همیشه بازنشانی کنید، هرگز یادآوری نکنید

تا حالا از شما خواسته شده که یک قابلیت یادآوری رمز عبور بسازید؟ یک لحظه عقب بایستید و این درخواست را از آخر به اول بررسی کنید: چرا به «یادآوری» نیاز است؟ چون کاربر رمز عبور خود را فراموش کرده است. واقعاً به دنبال چه چیزی هستیم؟ کمک کنیم تا دوباره وارد حسابشان شوند.

می‌فهمم – واژه‌ی «یادآوری» اغلب به‌صورت عامیانه استفاده می‌شود – اما هدف واقعی این است که به‌صورت امن به کاربر کمک کنیم تا دوباره آنلاین شود. چون می‌خواهیم امن باشد، دو دلیل وجود دارد که چرا یک یادآوری (یعنی واقعاً ارسال رمز عبور) کارساز نیست:

1. ایمیل یک کانال ناامن است. به همان روشی که اطلاعات حساس را از طریق HTTP ارسال نمی‌کنیم (بلکه از HTTPS استفاده می‌کنیم)، لایه انتقال برای ایمیل امن نیست. در واقع، این حتی بدتر از ارسال اطلاعات از طریق یک پروتکل انتقال ناامن است، زیرا ایمیل شما معمولاً در ذخیره‌سازی باقی می‌ماند، برای مدیران سیستم قابل دسترسی است، به‌راحتی فوروارد و توزیع می‌شود، توسط بدافزارها دسترسی پیدا می‌شود و غیره. ارتباط از طریق ایمیل یک کانال فوق‌العاده ناامن است.
2. شما نباید به رمز عبور دسترسی داشته باشید. به بخش ذخیره‌سازی برگردید – تنها چیزی که باید داشته باشید هش رمز عبور (با یک salt قوی) است، یعنی راهی برای بازیابی رمز عبور و ارسال آن به اطراف وجود ندارد.

اجازه دهید این مشکل را با استفاده از مثالی از usoutdoor.com نشان دهم: اینجا یک صفحه ورود معمولی است:

مشخصاً اولین مشکل این است که صفحه ورود با HTTPS بارگذاری نشده است، اما سپس آن‌ها گزینه‌ی «ارسال رمز عبور» را ارائه داده‌اند. شاید این همان استفاده‌ی عامیانه‌ای است که قبلاً اشاره شد، بیایید کمی عمیق‌تر شویم و ببینیم چه اتفاقی می‌افتد:

متأسفانه، اوضاع بهتر به نظر نمی‌رسد و ایمیل مشکل را تأیید می‌کند:

این موارد چیزهای مهمی درباره‌ی usoutdoor.com به ما می‌گوید:

1. آن‌ها رمز عبور را هش نمی‌کنند. در بهترین حالت، آن را رمزگذاری کرده‌اند، اما احتمالاً به‌صورت متن ساده ذخیره می‌کنند؛ هیچ مدرکی برعکس آن نداریم.
2. آن‌ها یک رمز عبور پایدار – چیزی که می‌توان دوباره و دوباره استفاده کرد – از طریق یک کانال ناامن ارسال می‌کنند.

حالا که این موضوع روشن شد، نکته این است که چگونه می‌توانیم اطمینان حاصل کنیم که فرایند بازنشانی به‌صورت امن انجام می‌شود و اولین گام برای انجام این کار، این است که تعیین کنیم درخواست‌کننده واقعاً مجاز به انجام بازنشانی است. به عبارت دیگر، به کمی تأیید هویت نیاز داریم، اما قبل از آن، بیایید ببینیم وقتی تأیید هویت انجام می‌شود بدون اینکه ابتدا مطمئن شویم درخواست‌کننده صاحب حساب است، چه اتفاقی می‌افتد.

شناسایی نام کاربری و تأثیر آن بر حریم خصوصی

بهترین راه برای توضیح این مشکل، استفاده از تصویر است. مشکل این است:

این پیام را می‌بینید؟ تمرکز کنید – پیامی که می‌گوید: «هیچ کاربری با این آدرس ایمیل ثبت نشده است» را بررسی کنید. مشکل اینجاست که وقتی سایتی چنین پیامی می‌دهد، در حقیقت تأیید می‌کند که کاربری با این ایمیل وجود دارد. و تمام! شما به‌تازگی علاقه‌مندی‌های مخفی همسر/رئیس/همسایه‌تان را فاش کرده‌اید!

البته که سایت‌های پورنو مثال بارزی از اهمیت حریم خصوصی هستند، اما ریسک مرتبط با تطبیق یک فرد با یک وب‌سایت خاص فراتر از یک افشای بالقوه شرم‌آور مانند این است. یکی از خطرات ناشی از این، مهندسی اجتماعی است؛ هنگامی که مهاجمی بتواند فردی را به یک سرویس مرتبط کند، قطعه‌ای از اطلاعات به دست می‌آورد که می‌تواند از آن بهره‌برداری کند. برای مثال، ممکن است با جعل هویت نماینده‌ی وب‌سایت با فرد تماس بگیرد و اطلاعات بیشتری را از او بخواهد، مانند حملات فیشینگ هدفمند.

این روش همچنین خطر “شناسایی نام کاربری” را باز می‌کند؛ یعنی مجموعه‌ای کامل از نام‌های کاربری یا آدرس‌های ایمیل می‌تواند تنها با ارسال درخواست‌های دسته‌ای و بررسی پاسخ‌ها، در وب‌سایت تأیید شود. اگر لیستی از ایمیل‌های دفتر کار دارید و چند دقیقه زمان برای اسکریپت‌نویسی، مشکل آشکار می‌شود!

راه‌حل چیست؟

در واقع، راه‌حل ساده است و Entropay آن را به‌خوبی اجرا کرده است:

کاری که Entropay انجام داده این است که هیچ اطلاعاتی در مورد وجود ایمیل در سیستم خود به کسی که مالک آن آدرس نیست، فاش نمی‌کند. اگر شما مالک آن آدرس باشید و آن در سیستم آن‌ها وجود نداشته باشد، یک ایمیل زیبا مانند این دریافت می‌کنید:

البته ممکن است موارد استفاده‌ی قانونی وجود داشته باشد که فرد فکر کند در وب‌سایتی ثبت‌نام کرده – اما نکرده – یا با ایمیلی متفاوت ثبت‌نام کرده است. پاسخ بالا هر دو سناریو را به‌خوبی مدیریت می‌کند. بدیهی است که اگر آدرس معتبر باشد، ایمیلی دریافت می‌کنید که امکان بازنشانی رمز عبور را فراهم می‌کند.

نکته در رویکرد Entropay این است که تأیید هویت از طریق ایمیل و پیش از هر نوع تأیید آنلاین انجام می‌شود. رویکردی که برخی وب‌سایت‌ها اتخاذ می‌کنند این است که قبل از شروع بازنشانی، از کاربر درخواست می‌کنند به یک سؤال امنیتی پاسخ دهد (بیشتر درباره این موضوع خواهیم گفت)، اما مشکل این روش این است که شما باید سؤال را همراه با ارائه‌ی نوعی شناسایی (ایمیل یا نام کاربری) پاسخ دهید که این امر تأیید وجود حساب را تقریباً غیرممکن می‌سازد بدون اینکه هویت کاربر ناشناس فاش شود.

بازنشانی رمز عبور در برابر ارسال URL بازنشانی

موضوع بعدی که باید بررسی کنیم مربوط به نحوه‌ی بازنشانی رمز عبور است و دو روش رایج وجود دارد:

1. تولید رمز عبور جدید در سرور و ارسال آن از طریق ایمیل.
2. ارسال یک URL یکتا که فرایند بازنشانی را تسهیل می‌کند.

با وجود راهنمایی‌های فراوان در خلاف جهت، روش اول جایی نیست که بخواهیم در آن باشیم. مشکل این روش این است که یک رمز عبور پایدار – چیزی که می‌توان دوباره و دوباره استفاده کرد – از طریق یک کانال ناامن ارسال شده و در صندوق ورودی شما ذخیره می‌شود. احتمالاً صندوق ورودی شما با دستگاه‌های موبایلتان همگام‌سازی می‌شود و ممکن است در سرویس ایمیل مبتنی بر وب شما برای مدت نامعلومی باقی بماند. نکته این است که صندوق پستی شما نباید به‌عنوان مکانی امن برای ذخیره‌سازی طولانی‌مدت در نظر گرفته شود.

اما مشکل بزرگ دیگری هم در روش اول وجود دارد: قفل کردن مخرب یک حساب کاربری را بسیار ساده می‌کند. اگر آدرس ایمیل کسی که مالک حسابی در وب‌سایت است را بدانم، می‌توانم هر زمان که بخواهم او را از حسابش قفل کنم، کافی است رمز عبور او را بازنشانی کنم. این همان حمله‌ی عدم ارائه‌ی خدمات (DoS) است که روی سینی نقره‌ای ارائه می‌شود! به همین دلیل است که بازنشانی چیزی است که تنها پس از تأیید موفقیت‌آمیز حق درخواست‌کننده باید انجام شود.

وقتی درباره‌ی یک URL بازنشانی صحبت می‌کنیم، منظورمان آدرس وب‌سایتی است که به‌صورت منحصربه‌فرد برای این مورد خاص از فرایند بازنشانی ایجاد شده است. بدیهی است که این URL باید تصادفی باشد و نباید چیزی باشد که بتوان حدس زد یا حاوی هیچ ارجاعی به حسابی که در حال تسهیل بازنشانی آن است باشد. برای مثال، یک URL بازنشانی نباید صرفاً مسیری مانند “Reset/?username=JohnSmith” باشد.

کاری که می‌خواهیم انجام دهیم، ایجاد یک توکن منحصربه‌فرد است که می‌توان آن را در یک ایمیل به‌عنوان بخشی از URL بازنشانی ارسال کرد و سپس آن را با رکوردی روی سرور، در کنار حساب کاربر مطابقت داد. به این ترتیب، مالک آدرس ایمیل تأیید می‌شود که همان کسی است که تلاش می‌کند رمز عبور را بازنشانی کند. برای مثال، این توکن ممکن است چیزی شبیه به “3ce7854015cd38c862cb9e14a1ae552b” باشد و در جدولی در کنار شناسه‌ی کاربری که بازنشانی را انجام می‌دهد و زمان ایجاد توکن ذخیره شود (بیشتر در این مورد خواهیم گفت). وقتی ایمیل ارسال می‌شود، حاوی یک URL مانند “Reset/?id=3ce7854015cd38c862cb9e14a1ae552b” است و وقتی کاربر این URL را بارگذاری می‌کند، صفحه وجود توکن را بررسی می‌کند و به همین ترتیب هویت کاربر تأیید شده و اجازه تغییر رمز عبور داده می‌شود.

البته، از آنجایی که فرایند فوق قرار است (امیدواریم) به کاربر امکان ایجاد یک رمز عبور جدید را بدهد، باید اطمینان حاصل کنیم که URL از طریق HTTPS بارگذاری شده است. خیر، ارسال به HTTPS کافی نیست؛ آن URL که حاوی توکن است باید از امنیت لایه انتقال (TLS) استفاده کند تا فرم رمز عبور جدید دچار حمله MITM نشود و رمز عبوری که کاربر ایجاد می‌کند از طریق یک اتصال امن ارسال شود.

مورد دیگری که باید با یک URL بازنشانی انجام دهیم این است که توکن را محدود به زمان کنیم تا فرایند بازنشانی فقط در مدت معینی، مثلاً ظرف یک ساعت، تکمیل شود. این کار باعث می‌شود که بازه‌ای که در آن بازنشانی می‌تواند انجام شود به حداقل برسد. بنابراین اگر کسی URL بازنشانی را به دست آورد، فقط در یک بازه زمانی بسیار محدود می‌تواند از آن استفاده کند. البته مهاجم می‌تواند دوباره فرایند بازنشانی را شروع کند، اما برای این کار نیاز به دریافت یک URL بازنشانی منحصربه‌فرد دیگر دارد.

در نهایت، باید اطمینان حاصل کنیم که این فرایند فقط یک‌بار مصرف است. پس از تکمیل فرایند بازنشانی، توکن باید حذف شود تا URL بازنشانی دیگر کار نکند. همان‌طور که در مورد قبلی اشاره شد، این کار برای اطمینان از محدود بودن بازه زمانی است که مهاجم می‌تواند از URL بازنشانی سوءاستفاده کند. به‌علاوه، پس از تکمیل موفقیت‌آمیز فرایند بازنشانی، توکن دیگر مورد نیاز نیست.

نقش CAPTCHA

آه CAPTCHA، تدبیری امنیتی که همه‌مان عاشق متنفر بودن از آن هستیم! در واقع، CAPTCHA بیشتر از اینکه یک اقدام امنیتی باشد، یک ابزار شناسایی است – آیا شما انسان هستید یا ربات (یا یک اسکریپت خودکار، همان‌طور که ممکن است باشد). هدف این است که از ارسال خودکار فرم‌ها جلوگیری شود، که البته می‌تواند به‌عنوان تلاشی برای نقض امنیت استفاده شود. در زمینه بازیابی رمز عبور، CAPTCHA به این معناست که امکان حمله brute force برای سوءاستفاده از قابلیت بازیابی یا تلاش برای شناسایی وجود حساب‌ها وجود ندارد (البته اگر دستورالعمل‌های بخش تأیید هویت را که قبلاً مطرح شد دنبال کرده باشید).

البته، CAPTCHA خود بی‌نقص نیست؛ موارد متعددی از “شکستن” آن به‌صورت برنامه‌ریزی شده با نرخ موفقیتی در حدود 60 تا 70 درصد وجود دارد. سپس به روشی می‌رسیم که من در مطلبم درباره “شکستن CAPTCHA با استفاده از انسان‌های خودکار” نشان دادم، که در آن می‌توانید با پرداخت مبلغی ناچیز به افراد، هر CAPTCHA را حل کنید و به نرخ موفقیت 94 درصد برسید. بنابراین، ایراداتی دارد، اما (کمی) مانع ورود را افزایش می‌دهد.

بیایید نگاهی به رویکرد PayPal بیندازیم:

در این حالت، فرآیند بازیابی رمز عبور تا زمانی که CAPTCHA حل نشود، نمی‌تواند آغاز شود؛ بنابراین، از لحاظ تئوری، نمی‌توانید این فرآیند را خودکار کنید. در تئوری.

اما برای بیشتر برنامه‌های وب، این اقدام بیش از حد سخت‌گیرانه خواهد بود و قطعاً منجر به کاهش کاربرپسندی می‌شود – مردم به‌سادگی CAPTCHA را دوست ندارند! همچنین CAPTCHA چیزی است که می‌توانید بعداً، در صورت نیاز، به سیستم اضافه کنید. اگر سرویس شروع به سوءاستفاده شود (اینجاست که ثبت‌وقایع اهمیت پیدا می‌کند – بعداً درباره این صحبت خواهیم کرد)، اضافه کردن CAPTCHA کار ساده‌ای است.

سؤالات و پاسخ‌های امنیتی

با آنچه تا کنون بررسی کرده‌ایم، توانستیم فقط با داشتن دسترسی به حساب ایمیل، رمز عبور را بازیابی کنیم. می‌گویم “فقط”، اما بدیهی است که دسترسی غیرقانونی به حساب ایمیل شخص دیگر باید کار دشواری باشد. اما همیشه این‌طور نیست.

در واقع، لینکی که در بالا به آن اشاره شد درباره هک شدن حساب Yahoo! “سارا پیلین” (Sarah Palin) است و دو هدف دارد؛ اول اینکه نشان می‌دهد چقدر ساده می‌توان به برخی حساب‌های ایمیل نفوذ کرد و دوم اینکه چطور سؤالات امنیتی ضعیف می‌توانند مورد سوءاستفاده قرار بگیرند – اما به این موضوع برخواهیم گشت.

مشکل بازیابی رمز عبور که 100٪ به ایمیل وابسته است این است که یکپارچگی حساب سایت موردنظر که در آن رمز عبور را بازیابی می‌کنید، کاملاً وابسته به یکپارچگی حساب ایمیل می‌شود. هر کسی که به ایمیل شما دسترسی داشته باشد، اکنون می‌تواند به هر حسابی که تنها با دریافت یک ایمیل بازیابی می‌شود دسترسی پیدا کند. برای این حساب‌ها، ایمیل شما در واقع کلید اصلی زندگی آنلاین شماست.

کاهش این خطر با سؤالات امنیتی

یکی از روش‌های کاهش این خطر، اجرای یک الگو بر اساس سؤال و پاسخ امنیتی است. بدون شک قبلاً این را دیده‌اید؛ انتخاب سؤالی که فقط خودتان باید پاسخ آن را بدانید و سپس ممکن است قبل از انجام بازیابی رمز عبور، به این سؤال پاسخ دهید. این روش مقداری اطمینان بیشتر می‌دهد که فردی که قصد بازیابی رمز عبور را دارد، مالک واقعی حساب است.

مشکل “سارا پیلین” این بود که پاسخ‌های او به سؤالات امنیتی به‌راحتی قابل کشف بودند. به‌خصوص اگر شخصیتی عمومی داشته باشید، اطلاعاتی مثل نام خانوادگی مادر، سابقه تحصیلی یا محل زندگی گذشته دیگر چندان محرمانه نیستند. در مورد “سارا”، چنین شد:

هکر، “دیوید کرنل” (David Kernell)، با بررسی جزئیات زندگی‌نامه‌ای مانند دبیرستان و تاریخ تولد “پیلین”، به حساب او دسترسی پیدا کرد و از ویژگی بازیابی رمز عبور Yahoo! استفاده کرد.

این در اصل یک نقص طراحی در Yahoo! بود؛ با ارائه یا اجازه چنین سؤالات ساده‌ای، آن‌ها به‌طور اساسی ارزش سؤال امنیتی و به تبع آن امنیت سیستم‌شان را تضعیف کردند.

یکی از گزینه‌ها این است که به کاربر اجازه دهید خودش سؤالات را تعریف کند، اما این کار مشکلاتی دارد:

اما مشکل این است که در این صورت ممکن است به سؤالات بسیار واضحی منتهی شوید. سؤالی مانند:

“رنگ آسمان چه رنگی است؟”

سؤالاتی که ممکن است وقتی از یک انسان برای تأیید هویت استفاده شود، افراد را در موقعیت ناراحت‌کننده‌ای قرار دهد (مثل در یک مرکز تماس):

“چه کسی را در مهمانی کریسمس بوسیدم؟”

یا سؤالات واقعاً بی‌معنی:

“چطور کلمه ‘رمزعبور’ را می‌نویسید؟”

وقتی صحبت از سؤالات امنیتی می‌شود، باید از خود کاربران محافظت کرد! به عبارت دیگر، سایت باید خودش سؤال امنیتی را تعریف کند، یا بهتر بگوییم یک سری سؤالات امنیتی را تعریف کند که کاربر از بین آن‌ها انتخاب کند. و نه فقط یکی؛ در ایده‌آل‌ترین حالت، کاربر باید دو یا چند سؤال امنیتی را هنگام ثبت‌نام تعریف کند که سپس به‌عنوان یک کانال دوم برای تأیید هویت استفاده شود. داشتن سؤالات متعدد، درجه‌ای بالاتر از اعتماد را به فرآیند تأیید هویت اضافه می‌کند و همچنین به شما این فرصت را می‌دهد که تصادفی بودن را اضافه کنید (یعنی همیشه همان سؤال نمایش داده نشود) و همچنین پشتیبانی از این موضوع که اگر فرد مشروعی جوابی را فراموش کرد، باز هم گزینه‌ای برای بازیابی وجود داشته باشد.

پس چه ویژگی‌هایی یک سؤال امنیتی خوب را می‌سازد؟ چندین عامل مختلف وجود دارد:

• باید مختصر باشد – سؤال دقیق و بدون ابهام است
• پاسخ باید خاص باشد – شما نمی‌خواهید سؤالی بپرسید که همان فرد پاسخ‌های متفاوتی به آن بدهد
• پاسخ‌های ممکن باید متنوع باشند – سؤالی درباره رنگ مورد علاقه فرد منجر به مجموعه‌ای کوچک از پاسخ‌ها می‌شود
• کشف پاسخ باید سخت باشد – اگر شما به‌راحتی می‌توانید پاسخ را برای هر کسی پیدا کنید (فکر کنید به افراد مشهور) این خوب نیست
• پاسخ باید ثابت باشد – پرسیدن از فیلم مورد علاقه کسی ممکن است در طول زمان تغییر کند

همچنین وب‌سایتی وجود دارد که به سؤالات امنیتی خوب اختصاص دارد که به‌طور غیرمنتظره‌ای در GoodSecurityQuestions.com است. برخی از این‌ها به‌نظر خوب می‌رسند، اما برخی دیگر برخی از تست‌های بالا را نمی‌گذرانند، به‌ویژه تست “کشف‌پذیری”.

اجازه دهید به شما نشان دهم که PayPal چگونه سؤالات امنیتی خود را اجرا می‌کند و به‌ویژه چقدر برای تأیید هویت افراد تلاش می‌کند. قبلاً صفحه‌ای را برای شروع فرآیند دیدیم (همان صفحه با CAPTCHA)، حالا وقتی آدرس ایمیل را وارد می‌کنید و CAPTCHA را حل می‌کنید، این اتفاق می‌افتد:

که منجر به ایمیلی مشابه این می‌شود:

تا اینجا همه‌چیز کاملاً معمولی است، اما این چیزی است که پشت آن لینک بازیابی قرار دارد:

خب، حالا سؤالات امنیتی وارد بازی می‌شوند. در واقع، PayPal همچنین اجازه می‌دهد که رمز عبور با تأیید شماره کارت اعتباری بازنشانی شود، بنابراین یک کانال اضافی وجود دارد که بسیاری از سایت‌ها به آن دسترسی ندارند. من به‌سادگی نمی‌توانم رمز عبور خود را تغییر دهم مگر اینکه هر دو سؤال امنیتی را پاسخ دهم (یا شماره کارت را بدانم). حتی اگر کسی به حساب ایمیل من دسترسی پیدا کند، نمی‌تواند حساب PayPal را بازنشانی کند مگر اینکه برخی اطلاعات خصوصی از من داشته باشد. این اطلاعات چه نوع اطلاعاتی هستند؟ این‌ها گزینه‌های سؤال امنیتی هستند که PayPal به شما می‌دهد:

سؤال درباره مدرسه و بیمارستان ممکن است کمی مشکوک باشد از نظر تست “کشف‌پذیری”، اما سایر سؤالات خیلی بد نیستند. اما برای افزایش امنیت، PayPal تأیید هویت بیشتری برای تغییر پاسخ‌های سؤالات امنیتی می‌خواهد:

PayPal یک مثال آرمان‌شهری از بازیابی رمز عبور امن است: آن‌ها از CAPTCHA برای جلوگیری از حملات brute force استفاده می‌کنند، دو سؤال امنیتی می‌خواهند و سپس برای تغییر پاسخ‌ها یک روش اضافی برای تأیید هویت می‌خواهند – و این پس از ورود به حساب است. البته از PayPal چنین انتظاری داریم؛ آن‌ها یک موسسه مالی هستند و پول زیادی را مدیریت می‌کنند. این به این معنا نیست که هر فرآیند بازیابی رمز عبور باید این مراحل را دنبال کند – این در بیشتر موارد زیاد است – اما این یک نقطه مرجع خوب برای زمانی است که امنیت موضوع جدی باشد.

یک نکته خوب درباره رویکرد سؤالات امنیتی این است که اگر از همان ابتدا آن را پیاده‌سازی نکردید، می‌توانید در صورت نیاز به آن اضافه کنید اگر پروفایل ریسک و دارایی که محافظت می‌کنید ایجاب کند. یک مثال خوب در این مورد اپل است که اخیراً این مکانیسم را راه‌اندازی کرده است. وقتی روزی برای به‌روزرسانی یک اپلیکیشن روی iPad رفتم، با این پیغام مواجه شدم:

این سپس صفحه‌ای را برای تعریف چندین جفت سؤال و پاسخ امنیتی و یک ایمیل نجات نشان داد:

مانند PayPal، سؤالات از قبل تعیین شده‌اند و برخی از آن‌ها واقعاً خوب هستند:

هر یک از سه جفت سؤال و پاسخ مجموعه‌ای متفاوت از سؤالات ممکن را ارائه می‌دهد، بنابراین راه‌های زیادی برای پیکربندی یک حساب وجود دارد.

چیز دیگری که باید در مورد پاسخ‌های سؤالات امنیتی در نظر بگیرید، ذخیره‌سازی آن‌ها است. قرار دادن آن‌ها در دیتابیس به‌صورت متنی ساده، مشابه خطرات ذخیره‌سازی رمز عبور، ریسک‌های مشابهی به همراه دارد، یعنی افشای دیتابیس به‌طور فوری مقدار آن را فاش می‌کند و نه تنها اپلیکیشن بلکه احتمالاً دیگر اپلیکیشن‌هایی که به همان سؤالات امنیتی وابسته هستند، در معرض خطر قرار می‌گیرند (این همان معضل آکای بری است). استفاده از هشینگ امن (الگوریتم قوی و نمک تصادفی رمزنگاری شده) یک گزینه است، اما برخلاف بیشتر سناریوهای رمز عبور، ممکن است دلیلی مشروع برای مشاهده پاسخ به‌صورت متنی ساده وجود داشته باشد. یک سناریو معمولی زمانی است که یک اپراتور انسانی در حال تأیید هویت از طریق تلفن است. اکنون، البته هشینگ همچنان ممکن است (اپراتور می‌تواند پاسخ را وارد کند)، اما در بدترین حالت، پاسخ باید حداقل مقداری رمزنگاری داشته باشد، حتی اگر فقط رمزنگاری متقارن باشد. نکته نهایی: پاسخ‌های امنیتی باید به‌عنوان پاسخ‌های محرمانه تلقی شوند!

تنها یک نکته دیگر در مورد سؤالات امنیتی و پاسخ‌ها – این‌ها بیشتر در معرض مهندسی اجتماعی هستند. تلاش برای به‌دست آوردن مستقیم رمز عبور حساب از کسی یک چیز است، اما شروع یک مکالمه با او درباره تاریخچه تحصیلی‌اش (یک سؤال رایج امنیتی) چیز دیگری است. در واقع، شما می‌توانید به‌طور مشروع با کسی درباره جنبه‌های مختلف زندگی‌اش صحبت کنید که می‌تواند به‌عنوان سؤال امنیتی محسوب شود و حتی شکی در آن ایجاد نکند. البته هدف اصلی سؤال امنیتی این است که به تجربیات زندگی کسی مربوط باشد تا به یاد ماندنی باشد و اینجاست که مشکل وجود دارد – مردم دوست دارند در مورد تجربیات زندگی‌شان صحبت کنند! کاری که می‌توانید انجام دهید این است که سؤالات امنیتی موجود به گونه‌ای تنظیم شوند که کمتر احتمال داشته باشد که بتوانند از طریق مهندسی اجتماعی از کسی استخراج شوند.

احراز هویت دو مرحله‌ای

هر آنچه تا اینجا خوانده‌اید مربوط به تأیید هویت بر اساس چیزهایی است که درخواست‌کننده می‌داند. او آدرس ایمیل خود را می‌داند، می‌داند چگونه به ایمیلش دسترسی پیدا کند (یعنی رمز عبور ایمیل خود را می‌داند) و پاسخ به برخی سوالات محرمانه را نیز می‌داند. «دانش» – یا چیزی که می‌دانید – به‌عنوان یک عامل احراز هویت در نظر گرفته می‌شود. دو عامل رایج دیگر عبارتند از: چیزی که دارید، مانند یک دستگاه فیزیکی، و چیزی که هستید، مانند اثر انگشت یا شبکیه چشم شما.

در بیشتر سناریوها، انجام احراز هویت زیستی تا حدی دشوار است، به‌ویژه وقتی صحبت از امنیت برنامه‌های وب می‌شود. بنابراین معمولاً از ویژگی دوم – چیزی که دارید – در احراز هویت دو مرحله‌ای (2FA) استفاده می‌شود. یکی از روش‌های رایج برای این عامل دوم، استفاده از یک توکن فیزیکی مانند RSA SecurID است:

موارد استفاده رایج از یک توکن فیزیکی شامل احراز هویت برای VPNهای شرکتی و خدمات مالی است. این فرآیند مستلزم احراز هویت به یک سرویس با استفاده از رمز عبور و کدی است که روی توکن نمایش داده می‌شود (که به‌طور مکرر تغییر می‌کند) و با یک PIN ترکیب می‌شود. در تئوری، مهاجم باید رمز عبور را بداند، توکن را در اختیار داشته باشد و PIN توکن را نیز بداند تا بتواند خود را شناسایی کند. در یک سناریوی بازنشانی رمز عبور، بدیهی است که رمز عبور مشخص نیست، اما داشتن توکن می‌تواند برای تأیید مشروعیت ادعای مالکیت حساب استفاده شود. البته مانند هر پیاده‌سازی امنیتی دیگری، این روش بی‌نقص نیست اما قطعاً سطح ورود را افزایش می‌دهد.

یکی از مشکلات اصلی این روش، هزینه و لجستیک پیاده‌سازی آن است؛ صحبت از توزیع دستگاه‌های فیزیکی برای هر مشتری و آموزش آن‌ها درباره یک فرآیند جدید است. علاوه بر این، مشتری باید در زمان نیاز واقعاً دستگاه را همراه داشته باشد، که این همیشه با توکن فیزیکی امکان‌پذیر نیست. گزینه دیگر، پیاده‌سازی عامل دوم احراز هویت با استفاده از SMS است که در یک سناریوی 2FA می‌تواند برای تأیید این موضوع استفاده شود که فردی که فرآیند بازنشانی را انجام می‌دهد، واقعاً تلفن همراه مالک حساب را در اختیار دارد. این روشی است که Google انجام می‌دهد:

اکنون باید احراز هویت دو مرحله‌ای فعال باشد. این بدان معناست که دفعه بعد که بخواهید رمز عبور خود را بازنشانی کنید، تلفن همراه شما می‌تواند به‌عنوان عامل دوم احراز هویت عمل کند. اجازه دهید نشان دهم که چگونه می‌توان این فرآیند را با آیفون من آغاز کرد، که دلایل آن به زودی مشخص خواهد شد:

پس از شناسایی آدرس ایمیل حساب، Google تشخیص می‌دهد که 2FA فعال شده است و می‌توانیم حساب را از طریق تأییدی که به شماره تلفن همراه مالک حساب ارسال می‌شود، بازنشانی کنیم:

اکنون باید انتخاب کنیم که فرآیند بازنشانی را آغاز کنیم:

یک ایمیل به آدرس ثبت‌شده ارسال می‌شود:

ایمیل حاوی یک لینک بازنشانی است:

وقتی به لینک بازنشانی دسترسی پیدا می‌کنید، یک SMS ارسال می‌شود و سایت درخواست می‌کند کد را وارد کنید:

این SMS ارسال شده است:

پس از وارد کردن آن در مرورگر، به بخش کلاسیک بازنشانی رمز عبور بازمی‌گردیم:

ممکن است این فرآیند کمی طولانی به نظر برسد – و همین‌طور هم هست (فکر می‌کنم آن صفحه سوم آیفون می‌تواند حذف شود) – اما این فرآیند تأیید می‌کند که فردی که بازنشانی را انجام می‌دهد، به هر دو آدرس ایمیل و تلفن همراه مالک حساب دسترسی دارد. این روش می‌تواند تا 9 برابر امن‌تر از کانالی باشد که فقط از ایمیل برای بازنشانی رمز عبور استفاده می‌کند. اما یک مشکل وجود دارد…

مشکل به گوشی‌های هوشمند مربوط می‌شود. دستگاهی که در تصویر زیر می‌بینید، تنها می‌تواند یک عامل احراز هویت را تأیید کند – می‌تواند یک SMS دریافت کند اما ایمیل نمی‌تواند:

اما این دستگاه می‌تواند یک SMS دریافت کند و یک ایمیل بازنشانی دریافت کند:

مشکل این است که وقتی ایمیل را به‌عنوان عامل اول احراز هویت و SMS (یا حتی یک اپلیکیشن تولید‌کننده توکن) را به‌عنوان عامل دوم در نظر می‌گیریم، این روزها همه این‌ها در یک دستگاه جمع شده‌اند. بدیهی است که اگر کسی گوشی هوشمند شما را به دست آورد، تمام این راحتی ناگهان به یک کانال بازمی‌گردد. آن عامل دوم یعنی «چیزی که دارید»، به این معناست که عامل اول را نیز در اختیار دارید. و همه این‌ها پشت یک PIN چهار رقمی است – اگر گوشی اصلاً PIN داشته باشد و قفل باشد.

بله، 2FA همان‌طور که Google آن را پیاده‌سازی کرده است، قطعاً امنیت بیشتری فراهم می‌کند، اما بی‌نقص نیست و قطعاً به دو کانال کاملاً مستقل وابسته نیست.

بازنشانی از طریق نام کاربری در مقابل بازنشانی از طریق آدرس ایمیل

آیا باید فقط امکان بازنشانی از طریق آدرس ایمیل را فراهم کنید؟ یا امکان بازنشانی از طریق نام کاربری نیز باید وجود داشته باشد؟ مشکل بازنشانی از طریق نام کاربری این است که هیچ راهی برای اطلاع‌رسانی به کاربر وجود ندارد اگر نام کاربری وارد شده نامعتبر باشد، بدون آنکه افشا کند فرد دیگری ممکن است حسابی با آن نام داشته باشد. در بخش قبلی، بازنشانی از طریق ایمیل تضمین می‌کرد که مالک قانونی آن ایمیل همیشه بتواند بازخورد دریافت کند بدون اینکه وجود حساب در سیستم به‌طور عمومی افشا شود. این کار با استفاده صرف از نام کاربری امکان‌پذیر نیست.

پاسخ کوتاه این است: فقط از طریق ایمیل. اگر بخواهید این کار را از طریق نام کاربری انجام دهید، با مواردی روبه‌رو خواهید شد که در آن کاربر متعجب می‌شود که چه اتفاقی افتاده یا شما وجود حساب‌ها را افشا می‌کنید. بله، فقط یک نام کاربری است و نه آدرس ایمیل، و بله، هرکسی می‌تواند هر نام کاربری (در دسترس) را انتخاب کند، اما همچنان احتمال زیادی وجود دارد که به دلیل استفاده مجدد از نام‌های کاربری، به‌طور ضمنی اطلاعات حساب‌ها را افشا کنید.

پس اگر کسی نام کاربری خود را فراموش کند چه اتفاقی می‌افتد؟ اگر فرض کنیم که نام کاربری همان آدرس ایمیل نباشد (که اغلب این‌گونه نیست)، فرآیند مشابه آغاز بازنشانی رمز عبور است – وارد کردن آدرس ایمیل و سپس ارسال پیامی به آن آدرس بدون افشای وجود آن. تنها تفاوت این است که این بار پیام شامل نام کاربری است، نه یک لینک بازنشانی رمز عبور. یا اینکه ایمیل توضیح می‌دهد هیچ حسابی با آن آدرس ثبت نشده است.

تأیید هویت و صحت آدرس‌های ایمیل

یکی از جنبه‌های کلیدی بازنشانی رمز عبور – و شاید مهم‌ترین جنبه – تأیید هویت فردی است که تلاش می‌کند بازنشانی را انجام دهد. آیا این واقعاً مالک قانونی حساب است؟ یا کسی که قصد دارد به حساب نفوذ کند یا صاحب حساب را به دردسر بیندازد؟

ایمیل به‌وضوح راحت‌ترین و فراگیرترین کانال برای تأیید هویت است. این روش بی‌نقص نیست و موارد زیادی وجود دارد که صرفاً امکان دریافت ایمیل‌ها در آدرس مالک حساب کافی نیست، به‌ویژه اگر به سطح بالایی از اطمینان هویتی نیاز باشد (به همین دلیل استفاده از 2FA ضروری است). اما تقریباً همیشه نقطه شروع فرآیند بازنشانی است.

نکته‌ای که اگر قرار است ایمیل در این فرآیند نقشی ایفا کند بسیار حیاتی است، این است که از همان ابتدا اطمینان حاصل شود که آدرس ایمیل صحیح است. اگر کسی یک کاراکتر را اشتباه وارد کند، طبیعتاً بازنشانی‌ها به مقصد نمی‌رسند. فرآیند تأیید ایمیل در زمان ثبت‌نام یک راه قطعی برای اطمینان از صحت آدرس است. همه ما این فرآیند را دیده‌ایم؛ شما ثبت‌نام می‌کنید، یک ایمیل حاوی یک لینک یکتا برای شما ارسال می‌شود که باید روی آن کلیک کنید و بدین ترتیب تأیید می‌شود که شما مالک آن آدرس ایمیل هستید. عدم امکان ورود به حساب کاربری تا زمانی که این فرآیند تکمیل نشود، انگیزه‌ای برای تأیید آدرس ایمیل ایجاد می‌کند.

مانند بسیاری از جنبه‌های امنیت، این مدل بهایی به‌صورت کاهش راحتی کاربر دارد، در ازای اطمینان بیشتر در مورد هویت کاربر. این موضوع ممکن است برای سایتی که کاربر ارزش زیادی برای ثبت موفقیت‌آمیز حساب قائل است و حاضر است یک گام بیشتر بردارد (مانند خدمات پولی، بانکداری و غیره) مناسب باشد. اما در مواردی که حساب صرفاً برای اهداف موقتی است، مثل گذاشتن نظر روی یک پست، ممکن است کاربر از آن صرف‌نظر کند.

شناسایی فردی که فرآیند بازنشانی را آغاز کرده است

به وضوح، امکان سوءاستفاده از ویژگی بازنشانی رمز عبور وجود دارد و افراد مخرب می‌توانند این کار را به روش‌های مختلف انجام دهند. یکی از ترفندهای ساده‌ای که می‌توان برای تأیید منبع درخواست استفاده کرد – و معمولاً هم مؤثر است – اضافه کردن آدرس IP درخواست‌دهنده به ایمیل بازنشانی است. این کار به گیرنده کمک می‌کند تا منبع درخواست را شناسایی کند.

در اینجا مثالی از ویژگی بازنشانی‌ای که هم‌اکنون در حال توسعه آن در ASafaWeb هستم آورده شده است:

آن لینک «اطلاعات بیشتر» شما را به سایت ip-adress.com هدایت می‌کند که اطلاعاتی مانند مکان و سازمان درخواست‌دهنده را ارائه می‌دهد:

البته، هر کسی که بخواهد هویت خود را مخفی کند، روش‌های متعددی برای پنهان کردن آدرس IP واقعی خود دارد، اما این یک روش ساده برای نسبت دادن نوعی هویت به درخواست‌دهنده است و در اکثر موارد به شما ایده‌ای خوب از این که چه کسی پشت درخواست بازنشانی بوده است می‌دهد.

اطلاع‌رسانی تغییرات از طریق ایمیل

یکی از تم‌های اصلی در این متن، اهمیت ارتباط است؛ باید تا حد ممکن به صاحب حساب اطلاع داد که در هر مرحله از فرآیند چه اتفاقی در حال رخ دادن است، بدون اینکه اطلاعاتی افشا شود که می‌تواند مورد سوءاستفاده قرار گیرد. همین اصل پس از تغییر رمز عبور نیز صادق است – باید به صاحب حساب اطلاع داد!

تغییر رمز عبور می‌تواند از دو منبع مختلف انجام شود:

1. تغییر رمز عبور در حالی که کاربر وارد سیستم است، زیرا صاحب حساب می‌خواهد رمز جدیدی تنظیم کند.
2. بازنشانی رمز عبور در حالی که کاربر وارد سیستم نیست، زیرا صاحب حساب رمز خود را فراموش کرده است.

اگرچه این مطلب عمدتاً درباره بازنشانی است، اما اطلاع‌رسانی در مثال اول می‌تواند خطر تغییر رمز عبور توسط شخص دیگری بدون اطلاع صاحب واقعی حساب را کاهش دهد. این وضعیت چگونه ممکن است اتفاق بیفتد؟ یک سناریوی رایج این است که فرد دیگری رمز عبور صاحب حساب را به دست آورده است (رمز عبوری که در جای دیگری لو رفته، از طریق کی‌لاگر ضبط شده یا به راحتی حدس زده شده است) و تصمیم گرفته آن را تغییر دهد و دسترسی او را مسدود کند. بدون اطلاع‌رسانی از طریق ایمیل، صاحب واقعی هیچ اطلاعی از این تغییر نخواهد داشت.

البته، در سناریوی بازنشانی، صاحب حساب قبلاً فرآیند را آغاز کرده (یا مراحل مختلف تأیید هویت را که در بالا توضیح داده شد، پشت سر گذاشته است)، بنابراین این تغییر نباید برای او تعجب‌آور باشد. اما اطلاع‌رسانی از طریق ایمیل بازخورد مثبت و تأیید اضافی ارائه می‌دهد. علاوه بر این، این اقدام باعث ایجاد یک تجربه یکسان در هر دو سناریوی بالا می‌شود.

و اگر هنوز واضح نیست، رمز عبور جدید را به آنها ایمیل نکنید! ممکن است خنده‌دار به نظر برسد، اما چنین چیزی اتفاق می‌افتد:

لاگ، لاگ و باز هم لاگ

ویژگی بازنشانی رمز عبور به شدت مستعد سوءاستفاده است، چه توسط مهاجمی که قصد دسترسی به حسابی را دارد یا فردی که صرفاً می‌خواهد برای صاحب حساب یا مدیر سیستم مشکل ایجاد کند. بسیاری از روش‌هایی که در بالا مورد بحث قرار گرفت، به کاهش سوءاستفاده کمک می‌کنند، اما نمی‌توانند آن را به طور کامل متوقف کنند و قطعاً نمی‌توانند جلوی تلاش افراد برای سوءاستفاده از این ویژگی را بگیرند.

یکی از روش‌هایی که برای شناسایی رفتارهای مخرب فوق‌العاده ارزشمند است، ثبت‌وقایع است. منظور ثبت‌وقایع گسترده است. تلاش‌های ناموفق برای ورود، بازنشانی رمز عبور، تغییر رمز عبور (برای مثال، زمانی که کاربر قبلاً وارد سیستم شده است) و اساساً هر چیزی که می‌تواند به شناسایی وضعیت در آینده کمک کند، باید ثبت شود. حتی بخش‌های مختلف فرآیند را ثبت کنید، برای مثال، یک ویژگی خوب برای بازنشانی شامل آغاز بازنشانی از طریق وب‌سایت (ثبت درخواست و تلاش برای بازنشانی با نام کاربری یا ایمیل نامعتبر)، ثبت بازدید از وب‌سایت با لینک بازنشانی (از جمله تلاش برای استفاده از یک توکن نامعتبر) و سپس ثبت موفقیت یا شکست در پاسخ به سؤال امنیتی است.

وقتی می‌گویم ثبت‌وقایع، فقط منظورم ثبت این نیست که صفحه بارگذاری شده است. باید تا حد ممکن اطلاعات جمع‌آوری کنید، به شرطی که حساس نباشد. لطفاً، رمز عبور را ثبت نکنید! آنچه باید ثبت کنید هویت کاربر تأییدشده (اگر در حال تغییر رمز عبور موجود هستند یا اگر در تلاش برای بازنشانی رمز عبور دیگری هستند در حالی که وارد سیستم شده‌اند)، نام‌های کاربری یا ایمیل‌های مورد تلاش و همچنین هر توکن بازنشانی‌ای است که تلاش کرده‌اند از آن استفاده کنند. اما شما همچنین باید مواردی مانند آدرس IP و حتی سربرگ‌های درخواست را در صورت امکان ثبت کنید. این کار به شما امکان می‌دهد نه تنها آنچه را که شخص (یا مهاجم) در حال تلاش برای انجام آن بوده، بلکه هویت آنها را بازسازی کنید.

واگذاری مسئولیت به ارائه‌دهندگان دیگر

اگر همه اینها به نظر کار سختی می‌آید، تنها نیستید. واقعیت این است که ایجاد یک سیستم مدیریت حساب امن ساده نیست. این کار از لحاظ فنی دشوار نیست، بلکه شامل جزئیات زیادی است. این فقط مربوط به بازنشانی نیست، بلکه شامل فرآیند ثبت‌نام، ذخیره ایمن رمز عبور، مدیریت چندین تلاش ناموفق برای ورود و موارد دیگر می‌شود. در حالی که من استفاده از قابلیت‌های از پیش ساخته‌شده مانند ASP.NET membership provider را توصیه می‌کنم، همچنان کار زیادی باید انجام شود.

امروزه ارائه‌دهندگان ثالث متعددی وجود دارند که خوشحالند این کارها را به جای شما انجام دهند و همه چیز را به یک سرویس مدیریت‌شده تبدیل کنند. گزینه‌ها شامل OpenID، OAuth و حتی Facebook هستند. برخی افراد به این مدل اعتقاد زیادی دارند (در واقع OpenID در Stack Overflow بسیار موفق بوده است)، اما برخی دیگر آن را به معنای واقعی کلمه یک کابوس می‌دانند.

بدون شک، سرویسی مانند OpenID بسیاری از مشکلات را از دوش توسعه‌دهنده برمی‌دارد، اما بدون شک مشکلات جدیدی نیز به همراه دارد. آیا این سرویس نقش مهمی دارد؟ بله، اما به وضوح می‌بینیم که ارائه‌دهندگان احراز هویت به طور گسترده پذیرفته نشده‌اند. بانک‌ها، خطوط هوایی و حتی فروشگاه‌ها – نمی‌توانم هیچ کدام را تصور کنم که از مکانیزم احراز هویت خود استفاده نکنند و دلایل بسیار خوبی هم برای آن وجود دارد.

بازنشانی‌های مخرب

یکی از نکات در مورد هر یک از مثال‌های بالا این است که رمز عبور قبلی تنها پس از تأیید هویت صاحب حساب غیرقابل‌استفاده می‌شود. این موضوع بسیار مهم است، زیرا اگر حساب قبل از تأیید هویت قابل بازنشانی باشد، راه برای انواع فعالیت‌های مخرب باز خواهد شد.

به عنوان مثال: فردی در حال شرکت در یک سایت حراج است و در مراحل پایانی پیشنهاددهی، با آغاز فرآیند بازنشانی، رقبا را از حسابشان قفل می‌کند و به این ترتیب رقابت را حذف می‌کند. به وضوح، در صورتی که یک ویژگی بازنشانی ضعیف طراحی شده باشد، می‌تواند نتایج منفی قابل‌توجهی به همراه داشته باشد. البته، قفل کردن حساب‌ها با تلاش‌های ناموفق برای ورود داستان مشابهی دارد، اما این موضوعی است که برای مطلبی دیگر می‌ماند.

همان‌طور که قبلاً اشاره کردم، دادن امکان بازنشانی حساب به کاربران ناشناس صرفاً با دانستن آدرس ایمیل، یک حمله انکار سرویس (DoS) است که منتظر وقوع است. شاید این حمله شبیه آن چیزی که معمولاً از DoS تصور می‌کنیم نباشد، اما هیچ راه سریع‌تری برای قفل کردن حساب کاربری کسی نسبت به یک ویژگی بازنشانی رمز عبور ضعیف وجود ندارد.

ضعیف‌ترین حلقه

همه آنچه در بالا خواندید برای ایمن‌سازی یک حساب عالی است، اما نکته‌ای که باید به آن توجه کنید، اکوسیستم اطراف حسابی است که در حال ایمن‌سازی آن هستید. اجازه دهید یک مثال بزنم:

ASafaWeb روی یک سرویس بسیار عالی به نام AppHarbor میزبانی می‌شود. فرآیند بازنشانی برای حساب میزبانی آنها به این صورت است:

مرحله 1:

مرحله 2:

مرحله 3:

مرحله 4:

پس از خواندن تمام اطلاعات قبلی در این مطلب، به راحتی می‌توان دید که در یک دنیای ایده‌آل، چند بخش وجود دارد که می‌توانستیم کمی متفاوت عمل کنیم. اما نکته‌ای که می‌خواهم در اینجا مطرح کنم این است که اگر سایتی مانند ASafaWeb را روی سرویس AppHarbor منتشر کنم و برخی سؤالات و پاسخ‌های امنیتی عالی پیاده‌سازی کنم، یک عامل احراز هویت دوم اضافه کنم و همه چیز را طبق اصول انجام دهم، هیچ‌کدام از این‌ها این واقعیت را تغییر نمی‌دهد که ضعیف‌ترین حلقه در فرآیند می‌تواند تمام این تلاش‌ها را بی‌اثر کند. به هر حال، اگر کسی بتواند با استفاده از اطلاعات ورود من به AppHarbor با موفقیت احراز هویت کند، می‌تواند تمام حساب‌های ASafaWeb را به هر رمزی که دوست دارد بازنشانی کند!

نکته این است که قدرت پیاده‌سازی امنیت باید به صورت کلی در نظر گرفته شود؛ باید تمام نقاط ورودی سیستم را مدل‌سازی تهدید کنید، حتی اگر این فرآیند ساده‌ای مانند بررسی سطحی AppHarbor باشد. این کار برای این کافی است که بفهمم چقدر باید در فرآیند بازنشانی رمز عبور ASafaWeb سرمایه‌گذاری کنم.

جمع‌بندی همه چیز

این مطلب شامل اطلاعات زیادی است، بنابراین اجازه دهید آن را به یک نمایش تصویری ساده خلاصه کنم:

همچنین به یاد داشته باشید که باید فعالیت‌ها را در هر چند نقطه ممکن ثبت کنید. و این تمام ماجراست – ساده!

خلاصه

اگر این مطلب جامع به نظر می‌رسد، تصور کنید که مطالب اضافی زیادی وجود دارد که می‌توانستم اضافه کنم اما به خاطر اختصار از آن صرف‌نظر کردم؛ مواردی مانند نقش یک آدرس ایمیل نجات، اتفاقاتی که در صورت از دست دادن دسترسی به ایمیل مرتبط با حساب می‌افتد (مثلاً تغییر شغل) و غیره. همان‌طور که قبلاً گفتم، بازنشانی‌ها دشوار نیستند، اما زاویه‌های زیادی دارند.

اگرچه بازنشانی‌ها دشوار نیستند، اغلب به شکلی ضعیف پیاده‌سازی می‌شوند. چند مثال در بالا دیدیم که چگونه این پیاده‌سازی‌ها می‌تواند به مشکلات منجر شود و موارد زیادی وجود دارد که در آنها بازنشانی‌های اشتباه مشکلات واقعی ایجاد کرده‌اند. همین چند روز پیش، به نظر می‌رسد که از یک بازنشانی برای سرقت 87 هزار دلار بیت‌کوین سوءاستفاده شده است. این یک نتیجه منفی جدی است!

بنابراین، در بازنشانی‌های خود دقت کنید، نقاط تماس مختلف را مدل‌سازی تهدید کنید و هنگام توسعه این ویژگی دیدگاه مهاجمان را در نظر داشته باشید، زیرا اگر این کار را نکنید، احتمالاً شخص دیگری این کار را خواهد کرد!