مقایسه روشهای تأیید OTP: پایگاه داده ، حافظه پنهان و رویکردهای مبتنی بر JWT

رمزهای عبور یک بار (OTPs) کدهای کوتاه مدت هستند که برای تأیید هویت کاربر در جریان مانند تنظیم مجدد رمز عبور ، ورود به سیستم یا تأیید اعتبار چند عاملی استفاده می شوند. OTP “یک رمز عبور تصادفی است که برای مدت زمان کوتاهی معتبر است (معمولاً 30 یا 60 ثانیه) … معمولاً یک کد عددی 6 یا 8 رقم” (مدیریت هویت و احراز هویت دو عاملی با استفاده از رمزهای عبور یک بار). از آنجا که آنها به طور مداوم تغییر می کنند و به سرعت منقضی می شوند ، OTP ها اطمینان می دهند که فقط شخصی که به ایمیل یا تلفن کاربر دسترسی دارد (چیزی که دارید) می تواند یک عمل حساس را انجام دهد. در عمل ، یک سرور OTP تولید می کند و آن را برای کاربر (از طریق ایمیل/پیام کوتاه) ارسال می کند ، سپس کاربر آن را برای تأیید در یک پنجره کوتاه ارسال می کند. این امر مانع از حمله مجدد می شود و تأیید می کند که کاربر کانال تحویل را کنترل می کند (به عنوان مثال ایمیل آنها).

با استفاده از OTPS یک لایه امنیتی اضافی اضافه می کند: حتی اگر یک رمز عبور به خطر بیفتد ، یک مهاجم هنوز به کد یک بار نیاز دارد. آنها به ویژه برای:

• تأیید ایمیل/تلفن: تأیید اینکه کاربر می تواند پیام را در یک آدرس یا شماره معین دریافت کند.
• احراز هویت دو عاملی: به عنوان یک عامل دوم (“چیزی که دارید”) در کنار رمز عبور.
• تأیید معامله/اقدام: تأیید عملیات حساس (به عنوان مثال نقل و انتقالات بانکی).

OTP ها ذاتاً محدود و یکبار مصرف هستند ، بنابراین سیستم ها معمولاً آنها را به زودی بعد از تولید یا اولین استفاده از آنها منقضی می کنند یا حذف می شوند (مدیریت هویت و احراز هویت دو عاملی با استفاده از رمزهای عبور یک بار).

روشهای سنتی ذخیره سازی OTP

ذخیره OTP در یک پایگاه داده

یک روش ساده برای ذخیره هر OTP در یک جدول پایگاه داده است. به عنوان مثال ، هنگامی که کاربر درخواست OTP می کند ، سرور کد تولید می کند و یک رکورد مانند را درج می کند (user_id, otp_code, expires_at) به یک پایگاه داده رابطه ای یا NOSQL. برای تأیید ، سرور از جدول پرس و جو می کند تا بررسی کند که OTP ارسال شده با کد ذخیره شده برای آن کاربر مطابقت دارد و منقضی نشده است. پس از موفقیت (یا انقضا) ، ورودی حذف شده یا مشخص شده است.

• اجرای: اگر قبلاً از یک پایگاه داده استفاده می کنید آسان است. برای وارد کردن ، پرس و جو و حذف سوابق ، به یک جدول/مجموعه برای OTP و منطق نیاز دارید. برخی از پایگاه داده ها پشتیبانی می کنند وقت به زندگی (TTL) ایندکس ها بنابراین OTP منقضی شده است. به عنوان مثال ، ویژگی TTL MongoDB “ساخت[s] امکان ذخیره داده ها … و MongoDB به طور خودکار داده ها را پس از تعداد مشخصی از ثانیه ها حذف می کنید. »(داده ها را از مجموعه ها با تنظیم TTL – Database Manual V8.0 – Docs MongoDB منقضی کنید) ، که ایده آل است زیرا OTP ها فقط به طور خلاصه مورد نیاز هستند.
• مقیاس پذیری: برای بار کم تا متوسط ​​کار می کند ، اما هر OTP نیاز به سفر دور به پایگاه داده دارد. تحت ترافیک سنگین ، این می تواند به یک تنگنا تبدیل شود یا نیاز به مقیاس بندی بانک اطلاعاتی داشته باشد.
• امنیت: سرور باید جدول OTP را تضمین کند. یک بانک اطلاعاتی نقض شده می تواند کدهای معتبر را نشت کند (هرچند که به سرعت منقضی می شوند). شما همچنین باید در برابر تزریق SQL/NOSQL محافظت کنید.
• وضعیت: این رویکرد است مطبوع – سرور حالت OTP را حفظ می کند. هر تأیید نیاز به جستجوی کد ذخیره شده دارد.
• عملکرد: به طور معمول کندتر از حافظه پنهان در حافظه. بانک اطلاعاتی می نویسد/می خواند که I/O و سربار معامله را می خواند.

نکته: برای تمیز کردن ورودی های قدیمی OTP از یک ویژگی TTL پایگاه داده یا یک کار Cron استفاده کنید ، زیرا آنها “فقط برای مدت زمان محدودی باید ادامه دهند” (داده ها را از مجموعه ها با تنظیم TTL – دفترچه راهنمای پایگاه داده v8.0 – اسناد MongoDB) منقضی کنید. در غیر این صورت ، OTP های بلااستفاده یا منقضی شده ، پایگاه داده را به هم می پیوندند.

ذخیره OTP ها در حافظه نهان در حافظه (به عنوان مثال Redis)

الگوی رایج دیگر استفاده از یک فروشگاه با ارزش کلیدی در حافظه مانند Redis است که برای داده های زودگذر مناسب است. در این روش سرور OTP تولید می کند و از Redis استفاده می کند SET فرمان برای ذخیره آن با یک انقضا کوتاه. به عنوان مثال ، بسیاری از پیاده سازی ها از ایمیل یا شناسه کاربر به عنوان کلید Redis و OTP به عنوان مقدار استفاده می کنند (اغلب با TTL 5-15 دقیقه):

// Pseudocode using Redis
const otp = generateOtp();
const key = `otp:${userEmail}`;   // e.g. "otp:alice@example.com"
redisClient.set(key, otp, 'EX', 300);  // expire in 300 seconds (5 mins)

برای تأیید ، سرور این کار را انجام می دهد redisClient.get(key) و آن را با کد ارسال شده مقایسه می کند. اگر آنها مطابقت داشته باشند ، سرور به طور معمول کلید را حذف می کند (DEL key) برای جلوگیری از استفاده مجدد. همانطور که در یکی از راهنما خاطرنشان می کند ، پس از یک مسابقه “OTP با استفاده از روش client.del (کلید) حذف می شود تا از آسیب پذیری جلوگیری شود” (اجرای تأیید OTP با استفاده از redis و node.js – dev community). در صورت عدم تطابق ، سرور تلاش را رد می کند.

• اجرای: کار کمی بیشتر برای تنظیم Redis ، اما ذخیره و بازیابی کلیدها ساده است (به عنوان مثال SET key value EX seconds). بسیاری از کتابخانه های مشتری این کار را آسان می کنند.
• مقیاس پذیری: بالا Redis در حافظه است و برای خواندن سریع/نوشتن بهینه شده است. این می تواند توان زیادی از درخواست ها را کنترل کند ، بنابراین به خوبی تحت بار سنگین مقیاس می یابد.
• امنیت: خطرات مشابه به عنوان یک بانک اطلاعاتی: سازش REDIS می تواند OTP های فعال را در معرض نمایش بگذارد. با این حال ، OTP ها به طور خودکار منقضی می شوند (و می توان در استفاده از آن حذف شد) ، و محدودیت پنجره قرار گرفتن در معرض. همیشه نمونه redis خود را ایمن کنید (بدون دسترسی عمومی باز).
• وضعیت: این هم هست مطبوعبشر سرور برای تأیید هر OTP باید از redis استفاده کند. با این حال ، به دلیل اینکه کلیدها در حال گسترش هستند ، دولت کوتاه مدت است.
• عملکرد: خیلی سریع جستجوی حافظه سفارشات بزرگی را سریعتر از پایگاه داده های مبتنی بر دیسک است. این به معنای تأیید سریعتر OTP و تأخیر کمتر برای کاربران است.

مثال در عمل: یک آموزش Node.js یک OTP 4 رقمی ایجاد می کند ، سپس تماس می گیرد client.set(email, otp) با استفاده از ایمیل کاربر به عنوان کلید (اجرای تأیید OTP با استفاده از Redis و Node.js – Community Dev). در حین تأیید client.get(email) و در یک مسابقه تماس می گیرد client.del(email) برای حذف آن (اجرای تأیید OTP با استفاده از redis و node.js – جامعه dev). این نشان می دهد که چگونه REDIS می تواند کدهای یک بار را به سادگی ذخیره کرده و پس از استفاده تمیز کند.

روش OTP رمزگذاری شده JWT

چگونه کار می کند

یک رویکرد جدیدتر با تعبیه OTP در داخل یک توکن وب امضا شده (و به صورت اختیاری رمزگذاری شده) JSON (JWT) ، از ذخیره سازی سمت سرور به طور کلی جلوگیری می کند. در این طرح ، هنگامی که کاربر درخواست OTP ، سرور:

1. یک کد OTP تولید می کند.
2. یک JWT (یا JWE) ایجاد می کند که بار آن شامل OTP و شناسایی اطلاعات است. به عنوان مثال ، بارگذاری ممکن است باشد { "user_id": 123, "email": "alice@example.com", "otp": 847135, "exp": }بشر
3. نشانه ها (و رمزگذاری) نشانه. این نشانه ممکن است یک JWE با استفاده از رمزگذاری متقارن (به عنوان مثال AES) باشد به طوری که فقط سرور می تواند آن را رمزگشایی کند ، یا یک JWS امضا شده در جایی که سرور به امضای بار اعتماد می کند.
4. OTP را به کاربر ارسال می کند از طریق ایمیل/پیام کوتاه و نشانه را به جبهه برمی گرداند (اغلب به عنوان یک پاسخ JSON). کاربر هرگز توکن را مستقیماً نمی بیند ، فقط کد OTP.

این جریان در یک مثال نشان داده شده است: سرور “ایجاد می کند[s] یک بار بار … آن را به عملکرد CREATE_TOKEN منتقل کنید. Payload شامل شناسه کاربر ، ایمیل کاربر ، OTP خود و انقضا است. پس از موفقیت موفقیت آمیز ، ما OTP را به ایمیل کاربر ارسال می کنیم و سپس پاسخ JSON حاوی نشانه را دوباره به جبهه ارسال می کنیم. »(تأیید OTP در چارچوب استراحت Django با استفاده از JWT و Cryptography | Geeksforgeeks). در کد ، ممکن است به نظر برسد:

otp = random.randint(100000, 999999)
payload = {
    "user_id": user.id,
    "email": user.email,
    "otp": str(otp),
    "exp": now + datetime.timedelta(minutes=5)
}
token = create_token(payload)   # encrypts/signs payload
send_email(user.email, f"Your OTP is {otp}")
return {"token": token}

(گزیده ای از مثال Django+JWT (تأیید OTP در چارچوب استراحت Django با استفاده از JWT و رمزنگاری | Geeksforgeeks).)

توکن در سمت مشتری ذخیره می شود (به عنوان مثال در حافظه مرورگر) یا به عنوان یک زمینه پنهان ارسال می شود. بعداً ، هنگامی که کاربر کد OTP را برای تأیید ارسال می کند ، مشتری این نشانه را به همراه OTP درج می کند. سرور سپس JWT را رمزگشایی/تأیید می کند ، بار را استخراج می کند و بررسی می کند که جاسازی شده otp با کد ارسال شده مطابقت دارد و این که نشانه منقضی نشده است. به دلیل “حقیقت” در مورد OTP در خود نشانه حمل نمی شود. اگر معتبر باشد ، سرور تأیید را می پذیرد.

جریان مثال

1. کاربر وارد ایمیل می شود: کاربر درخواست OTP می کند (به عنوان مثال با کلیک بر روی “ارسال کد” برای تنظیم مجدد رمز عبور).
2. سرور OTP و نشانه را صادر می کند: Backend تولید می کند otp=123456، JWT حاوی ایجاد می کند {"email":"user@example.com","otp":"123456","exp":}، رمزگذاری/آن را امضا می کند ، کد را به کاربر ایمیل می کند و JWT را به جلوی (تأیید OTP در چارچوب استراحت Django با استفاده از JWT و Cryptography | Geeksforgeeks) باز می گرداند.
3. کاربر OTP را ارسال می کند: کاربر ایمیل خود را بررسی می کند ، کد “123456” را می یابد و آن را به فرم وارد می کند. جبهه می فرستد { otp: "123456", token: "" } به سرور
4. سرور تأیید می کند: سرور JWT را رمزگشایی/تأیید می کند. این بار را بازیابی می کند otp و با کد ارسال شده مقایسه می شود. اگر آنها مطابقت داشته باشند و نشانه هنوز در پنجره انقضا آن قرار دارد ، تأیید موفقیت می کند. در غیر این صورت شکست می خورد.

این روش نیاز به ذخیره سازی OTP را روی سرور برطرف می کند. سرور فقط نیاز به مدیریت کلیدهای امضای JWT یا کلیدهای رمزگذاری دارد ، نه یک پایگاه داده یا حافظه نهان کدهای فعال.

مقایسه روشها

جدول: تفاوتهای کلیدی بین روشهای تأیید OTP.

مزایا و مضرات OTP مبتنی بر JWT

مزایای:

• بی تابعیت: سرور نیازی به یادآوری هرگونه OTP ندارد. این برای معماری های توزیع شده یا بدون سرور بسیار عالی است ، زیرا هر نمونه می تواند نشانه را بدون ذخیره مشترک تأیید کند.
• انقضاء داخلی: توکن exp زمینه به طور خودکار زمان را اجرا می کند (تأیید OTP در چارچوب استراحت Django با استفاده از JWT و Cryptography | Geeksforgeeks). پس از اتمام ، JWT (و OTP آن) نامعتبر است.
• بدون پاکسازی لازم نیست: بر خلاف DB یا حافظه نهان ، نیازی به پاکسازی پس زمینه OTP های قدیمی نیست – آنها به سادگی منقضی می شوند.
• فشرده سازی: تمام داده های لازم (کاربر ، OTP ، Timestamp) در یک نشانه جمع و جور سفر می کنند. برای خدمات میکروسرویس یا هنگامی که می خواهید از فروشگاه جلسه جلوگیری کنید مفید است.
• امنیت (با رمزگذاری): اگر JWT (JWE) را رمزگذاری کنید یا فقط اطلاعات غیر حساس را درج کنید ، OTP از مشتری و استراق سمع مخفی می شود. فقط سرور می تواند آن را با استفاده از کلید مخفی خود بخواند (رمزگذاری – آیا Token JWT باید رمزگذاری شود؟ – سرریز پشته).

مضرات:

• پیچیدگی: شما باید به درستی JWT امضای و رمزگذاری را پیاده سازی کنید. اشکالات می توانند امنیت را تضعیف کنند.
• توکن خطر سرقت: اگر یک مهاجم قبل از منقضی شدن یک نشانه را سرقت کند ، می تواند OTP آن را بخواند یا از آن استفاده مجدد کند (به خصوص اگر فقط امضا شود و رمزگذاری نشود). همانطور که اشاره شد ، بار JWT “هنوز هم برای هر کسی که آن را نگه می دارد قابل مشاهده است. اگر داده های حساس در آن بار دارید ، پس از رمزگذاری این ایده خوب است” (رمزگذاری – آیا باید رمزگذاری وب JWT رمزگذاری شود؟ – سرریز پشته). بنابراین شما باید از JWE استفاده کنید یا در غیر این صورت از آن محافظت کنید.
• ناتوانی در ابطال: پس از انتشار ، یک نشانه تا زمان انقضا معتبر است. هیچ راه آسانی برای ابطال OTP OTP تعبیه شده با JWT (کوتاه از اضافه کردن لیست ابطال سرور) وجود ندارد.
• اعتماد به مشتری: Token در سمت مشتری زندگی می کند (به عنوان مثال در حافظه مرورگر). دست زدن به ضعیف (نشت ، ذخیره طولانی) می تواند خطر را ایجاد کند.
• Crypto سربار: هر تأیید نیاز به رمزگشایی یا تأیید JWT دارد ، که سنگین تر از جستجوی حافظه پنهان ساده است. در سناریوهای با حجم بالا ، این هزینه CPU اهمیت دارد (اگرچه برای نشانه های کوتاه معمولاً جزئی است).

به طور خلاصه ، JWT OTP برای سیستم های بدون تابعیت قدرتمند است اما نیاز به کنترل دقیق کلیدها و نشانه ها دارد. بدون رمزگذاری ، هر داده ای در JWT (از جمله OTP) می تواند در معرض دید قرار گیرد (رمزگذاری – آیا باید توکن وب JWT رمزگذاری شود؟ – سرریز پشته) ، بنابراین رمزگذاری قوی و حمل و نقل HTTPS ضروری است.

ملاحظات امنیتی

• نشت توکن: همیشه از https استفاده کنید تا نشانه در ترانزیت رهگیری شود. اگر JWT به سرقت رفته باشد (به عنوان مثال از طریق XSS ، سیاهههای مربوط یا یک واسطه مخرب) ، یک مهاجم می تواند OTP را سرقت کند. اطمینان حاصل کنید که توکن ها طول عمر بسیار کوتاهی دارند (دقیقه).
• انقضا توکن: تنظیم کردن exp (انقضا) ادعای مدت زمان کوتاه. بهترین تمرین “حداکثر دقیقه یا ساعت در حداکثر” است (بهترین شیوه های امنیتی JWT | CULITY) ، نه روز. برای OTPS ، یک انقضا معمولی 5-15 دقیقه است. [24] توصیه می کند که از نشانه های طولانی مدت جلوگیری کنید.
• امضای و قدرت رمزگذاری: از الگوریتم های قوی استفاده کنید. برای نشانه های JWS ، از HMAC SHA-256 یا یک جفت RSA/ECDSA (به عنوان مثال RS256) با یک کلید قوی استفاده کنید. برای JWE ، از AES با حالت قوی استفاده کنید (به عنوان مثال AES-GCM یا Fernet's AES-CBC+HMAC). پایتون cryptography.Fernet اجرای (که اغلب برای چنین کارهایی استفاده می شود) از AES-128-CBC با HMAC-SHA256 استفاده می کند تا هم از محرمانه بودن و هم یکپارچگی اطمینان حاصل کند (فرنت چیست و چه زمانی باید از آن استفاده کنید؟) (سرخس چیست و چه زمانی باید از آن استفاده کنید؟). در هر صورت ، کلیدهای امضای/رمزگذاری خود را ایمن نگه دارید (در صورت لزوم بچرخید).
• ضمانت یک بار: حتی اگر این یک JWT باشد ، OTP را به عنوان یک کاربردی رفتار کنید. پس از تأیید موفقیت آمیز ، باید نشانه نامعتبر را در نظر بگیرید. برای JWT های بدون تابعیت ، این به طور معمول به معنای ساده اجازه می دهد تا منقضی شود و صدور جدید را صادر کند. از نشانه ها استفاده نکنید.
• محدود کردن داده های حساس: فقط ادعاهای لازم را شامل می شود. از email یا user_id (برای جستجوی) ، از قرار دادن اطلاعات حساس اضافی در نشانه خودداری کنید. [20] در صورت به دست آوردن نشانه (رمزگذاری – باید رمزگذاری وب JWT رمزگذاری شود؟ – سرریز پشته) ، پس از آن رمزهای عبور یا PII را در آن قرار ندهید. خود OTP حساس است ، بنابراین اطمینان حاصل کنید که در متن ساده قابل مشاهده نیست (از JWE استفاده کنید) یا فقط به طور خلاصه معتبر است.

تأثیر عملکرد و مقیاس پذیری

• بانک اطلاعاتی: عملکرد به DB شما بستگی دارد. در مقیاس پایین ، خوب است ، اما اگر باید هزاران درخواست OTP را در هر ثانیه انجام دهید ، DB می نویسد/خوانده شده گران می شود. پایگاه داده ها همچنین دیسک I/O ، سربار معامله ای و قفل را متحمل می شوند. در مقابل ، رویکردهای حافظه (Redis یا JWT) از بیشتر این موارد جلوگیری می کنند.
• redis: بسیار سریع و می تواند QP های بالا را کنترل کند. مجموعه/دریافت Redis زیر میلیسوت ثانیه می گیرد. حتی در سخت افزار متوسط ​​، Redis می تواند میلیون ها عمل در ثانیه انجام دهد ، بنابراین برای پایگاه های بزرگ کاربر خوب مقیاس می یابد. طبیعت در حافظه آن به این معنی است که جستجوی بسیار ارزان است. برای مقیاس بیشتر ، می توان Redis را خوشه بندی کرد. (با این حال ، Redis هنوز به تماس های شبکه به حافظه نهان مرکزی نیاز دارد مگر اینکه نمونه های محلی را در هر برنامه اجرا کنید.)
• روش JWT: تأیید بسیار سریع است زیرا شامل تماس های شبکه نمی شود – سرور فقط CPU برای تأیید/رمزگشایی نشانه کار می کند. این به طور معمول بخشی از میلی ثانیه را می گیرد. تجارت هزینه CPU است: عملیات رمزنگاری (HMAC یا AES) به محاسبات بیشتری نسبت به جستجوی حافظه نهان ساده نیاز دارند. در عمل ، برای ترافیک متوسط ​​، سربار CPU JWT در مقایسه با هزینه های شبکه/پایگاه داده اندک است. یک مزیت دیگر مقیاس گذاری واقعاً افقی است: از آنجا که هیچ فروشگاه OTP مشترک وجود ندارد ، می توانید بسیاری از نمونه های سرور بدون تابش را در پشت یک متعادل کننده بار بچرخانید ، و همه آنها از یک کلید امضاء یکسان برای تأیید هر نشانه استفاده می کنند.
• تأخیر: JWT به دلیل رمزنگاری ، تأخیر کمی بالاتری دارد ، اما این معمولاً کمتر از تأخیر یک پرس و جو DB یا یک تماس API خارجی است. همچنین ، JWT برای تأیید OTP به طور کلی از سفرهای دور پایگاه داده/شبکه ​​جلوگیری می کند.

به طور خلاصه ، برای در مقیاس عالی، رویکرد JWT می تواند از یک طرح پایگاه داده بهتر عمل کند زیرا تنگناهای ذخیره سازی متمرکز را از بین می برد. Redis در حال حاضر عملکرد بالایی را ارائه می دهد ، بنابراین JWT عمدتاً با از بین بردن جستجوی حافظه نهان به طور کامل در زمان تأیید ، با هزینه کار رمزگذاری کمک می کند.

چه زمانی از کدام روش استفاده کنیم

• رویکرد بانک اطلاعاتی: اجرای ساده هنگام شروع یا پروژه های بسیار کوچک. اگر قبلاً یک پایگاه داده کاربر و ترافیک OTP بسیار کم دارید ، ممکن است کافی باشد. همچنین اگر می خواهید حسابرسی آسان OTPS صادر شده ، یا اگر از ویژگی های TTL استفاده کرده اید (به عنوان مثال شاخص های MongoDB TTL (با تنظیم TTL – Database Manual V8.0 – Docs MongoDB) را منقضی کنید). با این حال ، با رشد استفاده ، آماده تغییر به چیز دیگری باشید.
• redis (حافظه نهان حافظه): یک انتخاب عالی برای اکثر برنامه ها پس از نیاز به سرعت و کارآیی. اگر از قبل از آن برای سایر داده های ذخیره یا جلسه استفاده می کنید ، از Redis استفاده کنید. این به خصوص خوب است اگر می خواهید Expiry Auto-Expiry (redis SET با EX یا SETEX) و رعد و برق می خواند. اجرای آن هنوز ساده است (فقط تماس های DB را با دستورات Redis جایگزین کنید) اما در مقیاس به طرز چشمگیری بهتر است.
• JWT رمزگذاری شده OTP: بهترین زمانی که به یک سرور کاملاً بدون تابعیت نیاز دارید یا در یک محیط میکروسرویس هستید. اگر درخواست شما در بسیاری از موارد توزیع شده است و می خواهید از هماهنگی وضعیت مشترک خودداری کنید ، JWT ایده آل است. همچنین وقتی می خواهید از هرگونه ذخیره سازی جلوگیری کنید (به عنوان مثال توابع بدون سرور) مفید است. اگر تخصص امنیتی دارید و به حداکثر مقیاس پذیری نیاز دارید ، این موضوع را انتخاب کنید. به خاطر داشته باشید که این پیچیده تر است – بنابراین از آن استفاده کنید که مزایای آن (بی تابعیت ، بدون وابستگی DB/Cache) از هزینه اجرای آن بالاتر باشد.

مشاوره کلیدی: برای مبتدیان یا سیستم های کوچک ، با Redis شروع کنید. این تعادل خوبی از سادگی و عملکرد است. فقط اگر به طور خاص به طراحی بدون تابعیت نیاز دارید یا برای مقیاس بسیار بزرگ برنامه ریزی کنید ، فقط JWT-OTP را اتخاذ کنید. همیشه اطمینان حاصل کنید که از هر روشی که استفاده می کنید دارای انقضا مناسب و اجرای یک کاربرد برای OTPS است.

پایان

OTP ها یک ابزار امنیتی اساسی برای تأیید کاربران از طریق کدهای کوتاه مدت است. به طور سنتی ، OTP ها سمت سرور (در یک پایگاه داده یا حافظه نهان) ذخیره می شوند و در هنگام ارسال بررسی می شوند. جدیدتر روش مبتنی بر JWT OTP را در یک نشانه امضا شده/رمزگذاری شده رمزگذاری می کند و نیاز به ذخیره سازی سرور را برطرف می کند. هر رویکرد دارای معاملات است:

• مجموعه پایگاه داده ذخیره سازی ساده اما دولتی و کندتر است.
• redis (حافظه پنهان) ذخیره سازی بسیار مطبوع اما بسیار سریع است و به راحتی منقضی می شود.
• نشانه های رمزگذاری شده JWT بدون تابعیت و مقیاس پذیر هستند اما نیاز به اجرای دقیق و مدیریت کلیدی دارند.

در همه موارد ، زمان انقضا کوتاه و انتقال ایمن بسیار مهم است. درک این روشها به شما امکان می دهد استراتژی مناسب را انتخاب کنید: به عنوان مثال از Redis برای ذخیره سازی سریع ، ذخیره سازی OTP زودگذر یا JWT برای یک معماری بدون تابعیت استفاده کنید. با وزن گیری سهولت اجرای ، امنیت و مقیاس پذیری (همانطور که در جدول بالا خلاصه شده است) ، می توانید روش تأیید OTP را برای برنامه خود انتخاب کنید.

منابع: راهنماهای عملی و نمونه هایی از سیستم های OTP ، استفاده مجدد و شیوه های امنیتی JWT
(مدیریت هویت و احراز هویت دو عاملی با استفاده از رمزهای عبور یک بار)

(اجرای تأیید OTP با استفاده از redis و node.js – جامعه dev)

(اجرای تأیید OTP با استفاده از redis و node.js – جامعه dev)

.

(بهترین شیوه های امنیتی JWT | Curity)

(داده ها را از مجموعه با تنظیم TTL – دفترچه راهنما V8.0 – اسناد MongoDB منقضی کنید).