چطور احراز هویت دو مرحله‌ای (2FA) را به اپ اضافه کنیم

برای افزودن احراز هویت دو مرحله‌ای (2FA) به اپ، به کاربران اجازه دهید یک برنامه احراز هویت را با اسکن کردن کد QR وصل کنند، بعد از رمز عبور، کد شش‌رقمی‌ای که آن برنامه نشان می‌دهد را بپرسید، و فقط وقتی آن کد درست بود روی سرور یک session کامل بسازید. به هر کاربر وقت روشن کردن آن کدهای بازیابی یک‌بارمصرف بدهید، تعداد حدس‌هایی که کسی می‌تواند بزند را محدود کنید، و برای خاموش کردن 2FA هم رمز عبور و یک کد فعلی را لازم بدانید. اگر از یک ارائه‌دهنده احراز هویت میزبانی‌شده استفاده می‌کنید، گزینه چندمرحله‌ای داخلی آن را روشن کنید، به‌جای ساختن خودتان.

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

قبل از شروع: یک ورود کاری لازم است

2FA روی یک ورود موجود قرار می‌گیرد. اول به یکی از این‌ها نیاز دارید:

• ورود خودتان، با کاربران و رمزهای عبور هش‌شده در پایگاه داده اپ.
• یک ارائه‌دهنده احراز هویت میزبانی‌شده که کاربران را برای شما مدیریت می‌کند.

اگر هنوز هیچ‌کدام را ندارید، با نحوه افزودن ورود به اپ شروع کنید. بقیه این راهنما فرض می‌کند یک مرحله رمز عبور از قبل کار می‌کند.

عامل دوم خود را انتخاب کنید

TOTP مخفف time-based one-time password است، یعنی استاندارد (RFC 6238) که برنامه‌های احراز هویت استفاده می‌کنند. سرور شما و گوشی کاربر یک راز مشترک دارند؛ هر دو از آن راز و زمان فعلی همان کد کوتاه را می‌سازند، که معمولاً هر ۳۰ ثانیه عوض می‌شود. نه اتصال شبکه لازم است نه ارائه‌دهنده پیامک.

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

خودتان بسازید یا روشن کنید؟

مستندات فعلی ارائه‌دهنده‌تان را بررسی کنید تا ببینید کدام عامل‌ها را پشتیبانی می‌کند و در کدام طرح‌ها. در هر حال، هرگز ریاضیات تولید کد را خودتان ننویسید؛ از یک کتابخانه پرکاربرد استفاده کنید.

اول سیاست را تعیین کنید

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

1. چه کسی باید از آن استفاده کند؟ برای همه اختیاری، برای مدیران و کارکنان الزامی، یا برای همه الزامی. الزام آن برای هر کسی که قدرت مدیریتی دارد رایج است. کنترل دسترسی بر اساس نقش را ببینید.
2. کاربران چند وقت یک کد دوباره وارد می‌کنند؟ در هر ورود، یا یک بار برای هر دستگاه به مدت ۳۰ روز («این دستگاه را به یاد داشته باش»).
3. کدام کارها به یک بررسی تازه نیاز دارند؟ تغییر ایمیل، اطلاعات پرداخت، یا خاموش کردن 2FA نامزدهای خوبی‌اند. به این احراز هویت گام‌به‌گام (step-up authentication) می‌گویند.
4. فرآیند گوشی گم‌شده چیست؟ کدهای بازیابی، به‌همراه یک روش دستی پشتیبان که حاضرید اجرا کنید.

مرحله به مرحله: 2FA با TOTP روی ورود خودتان

۱. فیلدهای درست را ذخیره کنید

هر کاربر به این‌ها نیاز دارد: اینکه 2FA فعال است یا نه، راز TOTP (رمزنگاری‌شده در حالت ذخیره، نه متن ساده)، زمان فعال شدن آن، و فهرست کدهای بازیابی که هش‌شده ذخیره شده‌اند، مثل رمزهای عبور. یک جا هم برای شمارش تلاش‌های ناموفق اضافه کنید.

۲. ثبت‌نام

1. کاربر تنظیمات را باز می‌کند و روی روشن کردن احراز هویت دو مرحله‌ای کلیک می‌کند.
2. سرور یک راز جدید می‌سازد و آن را به‌صورت کد QR برمی‌گرداند، به‌همراه نسخه متنی برای کسانی که نمی‌توانند اسکن کنند.
3. کاربر آن را در یک برنامه احراز هویت اسکن می‌کند و کد فعلی را تایپ می‌کند.
4. سرور کد را بررسی می‌کند. فقط اگر درست بود راز را ذخیره می‌کند و 2FA را فعال علامت می‌زند.
5. اپ ۸ تا ۱۰ کد بازیابی را یک بار نشان می‌دهد و از کاربر می‌خواهد آن‌ها را ذخیره کند.

مرحله ۴ مهم است: اگر 2FA را قبل از تأیید کد روشن کنید، هرکسی که اسکنش ناموفق بوده از ورود بعدی قفل می‌شود.

۳. ورود با یک مرحله دوم

1. کاربر ایمیل و رمز عبور را می‌فرستد. سرور آن‌ها را بررسی می‌کند.
2. اگر 2FA فعال است، سرور یک session کامل نمی‌سازد. به‌جایش یک وضعیت کوتاه‌مدت «عامل دوم در انتظار» ایجاد می‌کند.
3. اپ صفحه کد را نشان می‌دهد. سرور کد را بررسی می‌کند و یک پنجره کوچک برای انحراف ساعت مجاز است.
4. فقط حالا سرور session واقعی را صادر می‌کند.

هر route محافظت‌شده و هر endpoint API باید وضعیت در انتظار را رد کند. صفحه 2FA که فقط صفحات را در مرورگر پنهان می‌کند، با صدا زدن مستقیم API قابل دور زدن است.

۴. محدودیت‌ها و هشدارها

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

۵. بازیابی و خاموش کردن

• یک کد بازیابی یک بار کار می‌کند، بعد حذف می‌شود.
• خاموش کردن 2FA به رمز عبور و یک کد فعلی یا کد بازیابی نیاز دارد.
• ساختن دوباره کدهای بازیابی، مجموعه قبلی را باطل می‌کند.
• هر بار که 2FA روشن یا خاموش می‌شود، به کاربر ایمیل بزنید.

درخواست‌هایی برای ساز اپ هوش مصنوعی

با جریان اصلی شروع کنید:

احراز هویت دو مرحله‌ای اختیاری با برنامه‌های احراز هویت (TOTP) به ورود ایمیل و رمز عبور موجود اضافه کن. از یک کتابخانه TOTP شناخته‌شده استفاده کن و الگوریتم را خودت ننویس. در تنظیمات، یک کد QR و راز متنی نشان بده، و 2FA را فقط بعد از اینکه کاربر کد معتبر وارد کرد فعال کن. راز را رمزنگاری‌شده ذخیره کن و بعد از ثبت‌نام دوباره نشانش نده. ۱۰ کد بازیابی یک‌بارمصرف را یک بار نشان بده و هش‌شده ذخیره کن.

بعد اعمال سمت سرور، که جایی است که کد تولیدشده اغلب کم می‌آورد:

2FA را روی سرور اجرا کن. بعد از رمز عبور درست، کاربرانی که 2FA دارند یک وضعیت کوتاه‌مدت در انتظار می‌گیرند، نه یک session کامل. هر صفحه و route API محافظت‌شده باید وضعیت در انتظار را رد کند. تلاش کد را به ۵ محدود کن، بعد مرحله دوم را برای ۱۵ دقیقه قفل کن و به کاربر ایمیل بزن.

بعد سیاست:

2FA را برای حساب‌های مدیر الزامی کن: مدیری که 2FA ندارد به تنظیمات فرستاده شود و تا تکمیل آن به داشبورد دسترسی نداشته باشد. برای خاموش کردن 2FA یا تغییر ایمیل حساب، رمز عبور و یک کد فعلی را لازم کن. وقتی 2FA فعال یا غیرفعال می‌شود به کاربر ایمیل بزن.

در نهایت، از عامل بخواهید توضیح دهد چه ساخته است:

هر route را فهرست کن که بررسی می‌کند یک عامل دوم کامل شده، بگو راز TOTP و کدهای بازیابی کجا ذخیره می‌شوند و چطور محافظت شده‌اند.

اشتباهات رایج

• صادر کردن session بعد از رمز عبور. بزرگ‌ترین باگ. اگر session کامل قبل از بررسی کد وجود داشته باشد، 2FA فقط تزئین است. تست کنید با صدا زدن یک API محافظت‌شده فقط بعد از مرحله رمز عبور.
• بدون محدودیت تلاش. حدس‌های نامحدود کد را قابل شکستن با زور می‌کند.
• راز یا کد بازیابی به‌صورت متن ساده. اگر پایگاه داده نشت کند، عامل دوم همه را لو می‌دهد.
• فعال کردن قبل از تأیید. کاربرانی که اسکن اشتباه کرده‌اند در ورود بعدی قفل می‌شوند.
• بدون مسیر بازیابی. هر گوشی گم‌شده تبدیل به یک تیکت پشتیبانی یا یک مشتری از دست‌رفته می‌شود.
• خاموش کردن آسان. اگر یک session دزدیده‌شده بتواند 2FA را بدون کد خاموش کند، محافظت از بین رفته است.
• کدها و رازها در لاگ‌ها. مطمئن شوید کدها و رازها هرگز در لاگ سرور یا پیام‌های خطا ظاهر نمی‌شوند.
• بررسی فقط در صفحه ورود. بازنشانی رمز عبور، ورود با «لینک جادویی» و هر ورود اجتماعی هم باید 2FA را رعایت کنند، وگرنه راه دور زدن آن می‌شوند.

چک‌لیست تست

• ثبت‌نام فقط بعد از یک کد معتبر کامل می‌شود
• ورود با رمز عبور درست اما بدون کد، به هیچ صفحه یا API محافظت‌شده‌ای دسترسی نمی‌دهد
• کد اشتباه رد می‌شود؛ تلاش‌های اشتباه مکرر قفل و یک ایمیل را فعال می‌کنند
• کدی که چند دقیقه پیش بود رد می‌شود
• هر کد بازیابی دقیقاً یک بار کار می‌کند
• خاموش کردن 2FA به رمز عبور و کد فعلی نیاز دارد
• بازنشانی رمز عبور از 2FA عبور نمی‌کند
• مدیرانی که 2FA ندارند نمی‌توانند به صفحات مدیر دسترسی پیدا کنند (اگر الزامی باشد)
• راز و کدهای بازیابی در پایگاه داده رمزنگاری یا هش شده‌اند
• هیچ کد یا رازی در لاگ‌ها نیست

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

افزودن 2FA در Mythex

Mythex برای کاربران نهایی اپ شما سیستم ورود داخلی ندارد، پس 2FA بخشی از هر رویکرد احراز هویتی است که انتخاب می‌کنید: ورود خودتان با ایمیل و رمز عبور با استفاده از پایگاه داده پروژه، یا یک ارائه‌دهنده میزبانی‌شده با پشتیبانی چندمرحله‌ای. آنچه می‌خواهید را در چت با درخواست‌هایی مثل بالا توصیف می‌کنید، و کلیدهای ارائه‌دهنده در رازهای پروژه قرار می‌گیرند (از طریق /secrets، تنظیمات پروژه یا کارت رازهایی که عامل نشان می‌دهد) و نه در کادر پیام. راهنمای آماده افزودن ورود به اپ در مستندات یک درخواست شروع دارد، و امنیت برای اپ‌های ساخته‌شده عادات مربوط به کلیدها و مجوزها را پوشش می‌دهد. بعد از اینکه عامل کارش را تمام کرد، هر مورد چک‌لیست را در Preview تست کنید و بعد منتشر کنید.

پرسش‌ها