نوشته‌شده در

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

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

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

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

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

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

نوشته‌شده در

api – HMAC و با استفاده از فیلد تصادفی ایمن رمزنگاری به عنوان پیام

بگو که من یک برنامه بزرگ دارم که می خواهم یک API امن ایجاد کنم. راه های استاندارد رفتن این است که با کلید عمومی API و یک کلید API مخفی کار کنند و این را به کاربر ارائه دهند. بعد، در هر درخواست API، پیام ها با استفاده از MAC بر روی کلید مخفی و (بخشی از) پیام امضا می شوند.

اکنون، از آنجا که این برنامه بزرگ است، نمی خواهم انتخاب کنم در صورت درخواست API من برای پاسخ دادن به یک سؤال، message = answer ، اگر درخواست API من برای ارسال نظر بود message = comment و غیره …).

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

پرسش های من در حال حاضر است:

آیا این ایده خوبی است و چرا (نه) خیلی؟

نوشته‌شده در

ریسک کسب و کار – API Security – Mutual TLS vs TLS با رمز مشترک.

هر دو می توانند امن باشند، بنابراین حملات بالقوه در اینجا مهم نیست.

تفاوت ها در مدیریت هویت و کلید است.

با PSK (کلید مشترک به اشتراک گذاشته شده) شما فقط یک شناسه کلیدی برای مشتری، یک گواهی با صفات X.500 مانند نام مشترک نیست. بنابراین برای شناسایی هویت شما باید اطلاعات شناخته شده قبلی را به شناسه کلیدی پیوند دهید.

با PSK شما یک کلید مخفی را بین سرویس گیرنده و سرور به اشتراک می گذارید. اما اگر چندین مشتری یا سرور چندگانه وجود داشته باشد، لازم است کلید های بین بسیاری از اشخاص را به اشتراک بگذارید. با گواهی – یا به جای آن، زیرساخت کلید عمومی (PKI یا PKIX) با استفاده از گواهینامه ها ایجاد می شود – شما فقط باید یک راز (یا نسبتا خصوصی) کلید در هر نهاد داشته باشید. کلید عمومی می تواند مورد اعتماد باشد، اگر بخشی از یک گواهینامه در یک زنجیره گواهی باشد، بنابراین کلیدهای عمومی لازم نیست که توزیع شوند.

همانطور که قبلا اشاره کردید، بسیاری از گزینه های دیگر مدیریت کلید برای گواهینامه ها

یکی از معایب استفاده از certs این است که سرور cert معمولا نام سرور را شامل می شود و اتصال ممکن است بر روی میزبان های متفاوت نصب نشده باشد.

برای کسب و کار به کسب و کار من قطعا برای تأیید هویت مشتری / سرور با استفاده از گواهی ها. این رایج ترین و انعطاف پذیر ترین گزینه است. اطمینان حاصل کنید که فقط 19459005 گواهی هایی را که نیاز دارید (و نه همه گواهینامه هایی که به وسیله یک اعتماد معتبر اعتماد دارند) اعتماد کنید.