تأیید اعتبار – API برنامه تلفن همراه با استفاده از UDID و Argon2

من سعی میکنم یک برنامه iOS ایجاد کنم، این کد و همه را نوشتم، و در حال حاضر API هایی را برای برقراری ارتباط با پایگاه داده در اختیار دارم.

  • برنامه با استفاده از HTTPS و درخواستهای POST برای برقراری ارتباط با API استفاده می کند.
  • رمزهای عبور با استفاده از الگوریتم Argon2 هچ شده اند.
  • گزینه های ورود به سیستم 3rd party وجود ندارد (فیس بوک، G + و غیره)

در حالی که من API ها را پیاده سازی می کردم متوجه شدم که کاربر می تواند یک کاربر دیگر را جعل کند، اعتقاد دارد که هیچ هویت هویتی وجود ندارد، من ایده ی ID Auth را مطرح کردم و می خواهم ببینیم چقدر کارآمد است.

  • ایده: هر بار کاربر ورود به برنامه، برنامه UDID را دریافت می کند و آن را به API ارسال می کند و API آن را با استفاده از الگوریتم مشابه (Argon2) هش کرده و آن را در پایگاه داده ذخیره می کند، زمانی که کاربر سعی می کند انجام دهد، برای مثال، تغییر نام و یا ارسال یک پیام به یک کاربر دیگر، برنامه UDID را به API ارسال خواهد کرد تا هویت کاربر را تأیید کند، در صورت وجود، سپس اقدام انجام خواهد شد.

آیا امن است؟ اگر نه، چگونه می توانم آن را بهبود دهم، یا آنچه باید انجام دهم؟

تأیید اعتبار – آیا JWT نشانه ها را در مرورگر واقعا خلع سلاح می کند؟

توجه: من به طور کامل تصدیق می کنم ممکن است چیزی که من در تصویر از دست بدهم، بخشی از دلیل من برای ارسال. من می خواهم نظرات افراد بیشتری را تجربه کنم که از پیاده سازی های مربوط به authN / Z برخوردارم.

در اینجا این است که در این کل "هیچ نشانه های refresh در برنامه های مشتری" گیر کرده ام:

فرض من این است که بدون نشانه refresh ما نیز نمی توانیم، به دلیل دلایل تجربه کاربر، یک نشانه دسترسی بسیار کوتاه مدت داشته باشیم، یعنی اگر ما تا به حال یک نشانه دسترسی که هر 15 دقیقه منقضی می شود، بدون شادی برای تازه کردن ما مجبور به ورود دوباره هر 15 دقیقه.

مشکل من: با گسترش طول عمر نشانه دسترسی، ما یک مهاجم بالقوه MIDM را یک سلاح خطرناک تر می کنیم، یعنی نشانه ای که به منابع دسترسی دارد که می تواند روزها یا حتی برای همیشه باشد ( همانطور که در بسیاری از پروژه ها دیده ام.

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

  • همچنین یک JWT که منقضی می شود اما ممکن است منقضی شود در یک هفته یا بیشتر
  • یک نشانه "استفاده تنها یک بار" که برای نوشتن مجوز دسترسی مورد استفاده قرار می گیرد و پس از آن توسط یک نشانه تازه کردن جدید جایگزین می شود

به نظر من این رویکرد در برابر نشانه دسترسی طولانی مدت چندین مشکل را حل می کند:

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

    1. هنگامی که کاربر اصلی دوباره نشانه خود را دوباره تجسم می کند که نشانه قبلی بازنشانی دیگر نمی تواند قابل استفاده باشد
    2. اگر ما فرض کنیم کسی کسی را دزدی نشانه refresh ما در حالی که ما ' مرور مرورگر، در عرض چند دقیقه مرورگر ما سعی خواهد کرد که از آن کد بازنشانی استفاده کند، (زیرا شخص دیگری آن را استفاده کرده و بنابراین دیگر قابل استفاده نیست) و ما را به ورود به سیستم دعوت می کند که به طور کامل دیگر مجموعه ای از آخرین نشانه دریافت شده حتی در صورتی که 1 و 2 در هر سناریو صحت نداشته باشند (من من هستم
    3. چندین جلسه / تجدید نشانه اجازه داده شده است بنابراین نه یک پشته یا تازه کردن نشانه اما چند) من هنوز هم شرط می بندم که شما بهتر از جعل جوایز بازنشانی نامعتبر از هر روش که شما می خواهید از شما معتبر بودن توالی دسترسی است. یک نشانه دسترسی JWT به خودی خود معتبر است و کل هدف استفاده از آن این است که شما می توانید با تایید آن اعتماد کنید بدون اینکه دیگر عملیات گرانقیمت مانند چک کردن با سرور auth را در صورت اضافه بودن آن در لیست سیاه قرار دهید. این بدان معناست که نیاز به بررسی این نوع چیز برای هر درخواست هر بار با هر کدام از دسترسی ها انجام می شود = بسیار مقیاس پذیر نیست، به ویژه اگر شما این را مقایسه فقط به داشتن این نوع کار هر بار 15 دقیقه برای نشانه refresh (شما می توانید یک لیست سیاه لیست نشانه ها را نگه دارید)

بنابراین، با همه این گفته است، داشتن یک نشانگر بازنشانی "استفاده از یک بار" از طرف مشتری که همچنین JWT است و منقضی می شود که غیر منطقی است؟ ما از داشتن نشانه دسترسی در هفته گذشته اجتناب می کنیم، چگونه می تواند بد باشد؟

رمزگذاری – توابع مختلف هش برای اعتبار سنجی و PBE

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

با این وجود مطلوب است که قادر به اعتبار کلمه عبور باشیم. این سرویس به سادگی نمی تواند کلید PBE را ذخیره کند، زیرا داشتن این کلیدی اجازه می دهد تا فایل ها را رمزگشایی کند.

آیا برای استفاده از یک تابع هش دیگر برای تأیید اعتبار کلمه عبور و ذخیره آن کافی است؟ اگر چنین است، آیا انتخاب پیشنهادی PBE + هش برای جلوگیری از اشتباه وجود دارد؟

eidas – چگونه می توان اعتبار یک لیست اتحادیه اروپا از لیست های اعتماد معتبر بود؟

برای اعتبار دادن اینکه آیا اعتبار سرویس واجد شرایط است، باید کلید عمومی را در یک لیست اعتبار (TL) کشور عضو جستجو کند.

برای تایید اینکه آیا TL یک کشور عضو معتبر است، باید جستجو کند کلید عمومی که دولت عضو TL را در لیست اتحادیه های اعتماد اتحادیه اروپا امضا کرد.

فرآیند تأیید اعتبار فهرست فهرست اعتبار اتحادیه اروپا معتبر است

در نسخه فعلی (شماره توالی 208) امضا شده توسط کلید عمومی صادر شده به Maarten Joris Ottoy توسط Luxtrust. چگونه باید تأیید کنیم که آقای جوریس دارای مجوز برای امضای لیست لیست اعتماد است؟

آزمون نفوذ – hostapd-wpe یک چالش و واکنش دریافت می کند، به طور متوسط ​​اعتبار ارسال شد؟

یک نقطه دسترسی برای راه اندازی یک حمله "شر دوقلو" در یک شبکه سازمانی WPA2 موجود ایجاد کردم (من اجازه دارم این کار را انجام دهم)

من با استفاده از hostapd-wpe، در کوتاه مدت از امکان دسترسی به نقطه دسترسی من دستگاه ها شبکه را می بینند و احراز هویت می کنند و من یک چالش و پاسخ می گیرم.

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

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

john – wordlist = / usr / share / wordlists / rockyou .txt.gz hash.txt

john –format = netntlm – naive –wordlist = / usr / share / wordlists / rockyou.txt.gz hash.txt

وقتی mschapv2 یا netntlmv2 را در jtr یا hashcat امتحان میکنم آن را بارها 0 هش. hashcat خطایی در مورد salt-length ارائه می دهد.

hostapd-wpe نشان می دهد که چالش و پاسخ mschapv2 است.

به دنبال یک پاسخ ساده اما هر گونه توصیه بسیار قدردانی است. آیا چالش و واکنش نشان می دهد که این ماشین ها فقط اعتبارنامه خود را به AP شر دوقلو ارسال کرد، و من فقط نیاز به ادامه کار در فهم چگونگی برداشتن mschapv2. یا اینکه چالش و پاسخ را لزوما به معنی موفقیت نیست و ممکن است برای ادامه کار بر روی AP شر دوقلو باید ادامه داشته باشد.

از زمان شما متشکرم.