گذرواژهها – آیا OTP من با توجه به عملکرد بانکی امن نیست؟

اکثر بانک ها از OTP (رمز عبور یک بار) برای غنی سازی احراز هویت از طریق عامل دوگانه استفاده می کنند.

اما من مشاهده کردم که بانک ها OTP را به موبایل و همچنین ایمیل ارسال می کنند.

امن نیست و کارشناس توصیه های امنیتی توصیه نمی شود.

زیر ایمیل نمونه ای است که با OTP به موبایل دریافت می کنم:

 اینجا را وارد کنید تصویر

آیا OTP من نیست امن با توجه به عملکرد بانک؟ یا من چیزی از دست رفته در اینجا؟

استانداردها – زمان حیات برای SMS OTP چیست؟

من سعی کردم چنین استانداردی را بیابم که عمر OTP SME را ذکر می کند، با این حال، NIST دیگر با استفاده از SMS OTP توصیه نمی شود.

صرف نظر از نگرانی های امنیتی، هنوز نیاز به پیاده سازی دارم SMS OTP و مایل به شناخت معیارهای استاندارد در اجرای OTP SMS است. چه مدت طول می کشد، چه مدت باید کاربر صبر کند تا او بتواند برای OTP دیگری درخواست کند، آیا کاربر دوباره می تواند همان OTP را درخواست کند؟

احراز هویت – اس ام اس OTP به عنوان 2FA – آیا باید اس ام اس در اس ام اس برای تایید کاربر وجود داشته باشد؟

چند بار من پیاده سازی SMS 2FA را هنگامی که یک وب سایت نشان می دهد "sms id session" (به عبارتی، 8 رقمی نشانگر) را بلافاصله پس از ارسال اس ام اس به کاربر همراه با OTP فوری نشان می دهد. اس ام اس همراه با OTP (به عنوان مثال، 4 رقم) و شناسه اس ام اس (8 رقمی).
پس از آن کاربر باید شناسه session id اس ام اس در اس ام اس را در UI وب سایت و تنها پس از آن OTP را وارد کنید. اگر اسم شناسه جلسه مطابقت نداشته باشد، کاربر باید متوقف شود و از ورود OTP جلوگیری کند.

تعجب این نوع گردش کاری است که به دلایل امنیتی ساخته شده است؟ و تأیید اسناد session id از برخی از حملات محافظت می کند

یک مثال از چنین گردش کار: webmoney.ru

تأیید هویت – هویت شخص ثالث با OTP

اول از همه می خواهم اشاره کنم که من کاملا انجام می دهم NOT میخواهم رمز عبور خودم را به هیچ وجه اجرا نکنم. من فقط در مورد این موضوع فکر کردم و بعد از تحقیقاتی، راه حل خوبی پیدا نشد.

امیدوارم که یک راه حل شناخته شده برای این مشکل وجود داشته باشد که من نمیتوانم پیدا کنم.

فرض کنید سه طرف متعاقب وجود دارد:

  • مشتری : فرض کنید یک گوشی هوشمند
  • uC : یک میکروکنترلر شبکه با یک کانال ناامن اضافی به سرور
  • : برخی از جادوگران باطن سرور دارای یک پایگاه داده است و برای هر دو، سرویس دهنده و UC، سرویس معتبر وب را تأیید می کند

دستیابی به تأیید اعتبار از مشتری در برابر دستگاه UC با استفاده از رمز عبور یک بار در زیر فرض های زیر؟

  • مشتری نباید قادر به تأیید هویت خود را قبل از اینکه سرور آن را "OK" داده است. فرض کنید برخی از فرایند رزرو / خرید و UC اقدام به اجازه دسترسی
  • اسرار ممکن است بین سرور <-> مشتری و بین سرور <-> uC
  • مشترک است. کانال بین مشتری و دستگاه UC باید به عنوان ناامن
  • یک کاربر ممکن است چندین مشتری داشته باشد که همه باید قادر به تأیید هویت باشند
  • دستگاه UC تنها یکی از بسیاری در زمینه است، بنابراین مشتری باید بتواند در برابر هر یک از آنها هویت ساز شود
  • Client و سرور با استفاده از یک API REST ارتباط برقرار می کند
  • دستگاه UC به وضوح محدود محاسبات قدرت / ذخیره سازی است، اما همچنین با استفاده از یک API REST برای برقراری ارتباط با سرور
  • تمام ارتباطات API از طریق TLS انجام می شود

آیا MSC زیر امکان پذیر است؟ ایده من اساسا برای استفاده از یک زنجیره هش برای ایجاد OTP بود. اما از آنجا که مشتری نباید راز ایجاد هش را بداند، نسل OTP توسط سرور انجام می شود.

 + --------- + + --------- + + ----- +
| مشتری | | سرور | | uC |
+ --------- + + --------- + + ----- +
    | | | ---------------- 
    | | | - | فروشگاه ها h ^ n (p) |
    | | | | و n = 1000 |
    | | | | --------------- |
    | | ----------  |
    | | - | می داند p | |
    | | | و n | |
    | | | --------- | |
    | | |
    | درخواست دسترسی | |
    | ----------------------> | |
    | | ------------------  |
    | | - | بررسی کنید که آیا دسترسی | |
    | | | ممکن است اعطا شود |
    | | | ----------------- | |
    | | |
    | OTP = h ^ (n-1) (p) | |
    | <----------------------|                                  |
    |                       |                                  |
    | OTP                   |                                  |
    |---------------------------------------------------------> |
    | | | ----------------- 
    | | | - | دسترسی به دسترسی |
    | | | | فروشگاه OTP، n-- |
    | | | | ---------------- |
    | | |
    | | دسترسی به مجوز |
    | | اگر n == 0: ایجاد جدید h ^ 1000 (p) |
    | | <---------------------------------|
    |                       | ----------------------          |
    |                       |-| save granted access |          |
    |                       | | n--                 |          |
    |                       | |---------------------|          |
    |                       |                                  |
    |                       | OK, h^1000(q) if needed          |
    |                       |---------------------------------> |
    | | |

EDIT : فقط در مورد پنج دقیقه دیگر فکر کردم، متوجه شدم که این راه خوبی برای حل این مسئله نیست، زیرا سرور اساسا راز و فهرست زنجیره هش را ذخیره می کند. بنابراین در صورت نقض داده ها، OTP ها برای محاکمات بعدی n شناخته می شود.

آیا می توان این را تنها با ذخیره کردن فهرست زنجیره های هش در دستگاه UC حل کرد و تنها یک بار به سرور این ارتباط برقرار می کند؟ به عنوان مثال اگر مشتری مشتری UC برای شاخص فعلی خود را قبل از درخواست دسترسی از سرور نمایش دهد؟

رمز عبور یک بار – جلوگیری از سوء استفاده از OTP در جریان ثبت نام برنامه

این ممکن است به نظر یک سوال open ended باشد، اما من می خواهم شانس خود را بگیرم و درک کنم که آیا بقیه جامعه در حال رسیدگی به این مسئله هستند.

بیایید بگویم برنامه ای است که به کاربران امکان می دهد ثبت نام با استفاده از شماره تلفن خود را.

پلتفرم برنامه

  1. Android
  2. iOS

برنامه جریان

  1. کاربر برنامه را باز میکند
  2. او با یک دکمه ورود / ثبت نام ارائه میشود
  3. اکنون میخواهد ثبت نام کند او یک کاربر جدید است. بنابراین او بر روی دکمه ثبت نام کلیک می کند و از او برای شماره تلفن او
  4. خواسته می شود وقتی شماره تلفن خود را ارسال می کند، او را از طریق SMS دریافت می کند. بگو که برنامه در واقع از API / ثبت نام که اس ام اس را راه اندازی می کند تماس می گیرد

خطر:
در حال حاضر برای هر SMS خروجی، هزینه های مالی درگیر است.

اقدامات پیشگیرانه / واکنشی کاهش یافته

  1. API نرخ محدود است (بر اساس شماره تلفن)
  2. نظارت و هشدار درست در محل وجود دارد. بنابراین اگر در همه موارد موارد سوء استفاده وجود داشته باشد، اقدامات شدید مثل مسدود کردن IP ممکن است رخ دهد.

مسائل

  1. اگر یک دشمن (به طور بالقوه یک رقیب) با API برخورد کند
    شماره تلفن های مختلف، منطق محدود کردن سرعت را به راحتی دور می اندازد.
  2. مسدود کردن IP همیشه ممکن نیست. بگو: اگر دشمن پشت شبکه NATed باشد، تمام کاربران واقعی پشت شبکه نیز از انجام هر گونه ثبت نام موفقیت آمیز مسدود می شوند.
  3. اگر دشمن تغییر آی پی ها (شاید با استفاده از Tor)، مرحله دوم کاهش در موارد فوق نیز از بین می رود.
  4. Captcha یک راه حل نیست زیرا آن را از بین می برد UX، مخصوصا هنگام برخورد با برنامه های تلفن همراه
  5. داشتن نام کاربری رمز عبور به جای OTP برای تأیید ثبت نام یک گزینه نیست، زیرا برنامه نیاز به یک شماره تلفن تأیید شده برای کارکردن دارد
  6. امضای دستگاه در هر دستگاه نیز می تواند به عنوان یک عامل برای محدود کردن سرعت استفاده شود، اما واقعیت این است که از دستگاه نیز بیش از HTTP (ها) می آید. از این رو، به راحتی قابل تغییر است. بنابراین این گزینه نیز غیرقانونی است.

در چنین وضعیتی، چگونه در برابر ریسک محافظت شود یا شاید بتوان آن را برای آن آماده کرد، اگر در کل نمیتوان آنرا مرتب کرد؟