ذخیره حالت لاگین در سرور - ضروری

[raha_jon]

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

[aliireza]

برای این کار بجز shared preference فکر نکنم امکان دیگه‌ای باشه. اطلاعات مورد نیاز مثل device id و username‌ وبقیه رو ذخیره میکنی و میشه به صورت دوره‌ای این اطلاعات رو با سرور چک کرد که صحیح باشه.

[raha_jon]

ممنون
اگه shared preference دزده بشن چی؟
لطفا بحث کنیم ی راه امین پیدا کنیم ممنون مطمئن هستم برا ههمون لازم میشه

[raha_jon]

بفرما بالا

[karl2008]

اینکار بروی دیتابیس سرور انجام بشه بهتره .بعنوان مثال یک کد یکتا از هر گوشی با ترکیبی از android id و مدل و ... رو در هنگام اجرای برنامه تون به سرور ارسال کنید (بدون اینکه این کد یکتا در گوشی ذخیره بشه) و در کنار ستون جدول کاربر فیلدی برای اینکه کاربر آخرین بار لاگین کرده یا نه در سرور ذخیره کنید.
جدول کاربر در سرور :
device_uniqe_id----> string
hasLogin-----> boolean
,....
در صورتی که کاربر logOut هم کنه ، این مقدار hasLogin رو به سرور بفرستید تا اگر بعدا برنامه تون توسط همون کاربر اجرا شد،ازش درخواست لاگین بشه.

[Nevercom]

یکی از راه حل های مناسب، استفاده از توکن (Token) هست.
الگو به این شکل هست:

1. اگر هیچ توکنی موجود نبود، نیاز به لاگین هست
2. کاربر برای لاگین اطلاعات ورود رو میفرسته به سرور و در صورت موفقیت یک توکن براش تولید میشه و در پاسخ براش فرستاده میشه (این توکن در سیستم کاربر ذخیره میشه و نقص امنیتی هم نیست چون فقط برای اون یوزر خاص هست)
3. از این به بعد در هر درخواستی که کاربر ارسال می کنه، توکن رو هم میفرسته
4. سمت سرور اعتبار توکن چک میشه و اگر معتبر بود عملیات موردنظر انجام میشه و اگر نه پیغام خطای مناسب برای ارسال میشه
5. اگر سرور پاسخ داد که توکن معتبر نیست، مرحله ی ۱ تکرار میشه.

این توکن در سرور تولید میشه و در دیتابیس همراه با اطلاعات مورد نیاز برای تشخیص کاربری که اون توکن بهش نسبت داده شده و تاریخ اعتبار توکن ذخیره میشه.
از روی توکن ما می‌فهمیم که کدوم کاربر این درخواست رو ارسال کرده و به کلاینت برای تشخیص کاربر تکیه نمی‌کنیم.

الگوی مناسب تر استفاده از JWT یا JSON Web Token هست. در JWT اطلاعات در دیتابیس ذخیره نمیشه که باعث میشه درخواست های دیتابیسی خیلی پایین تر بیاد و در عوض از کلیدهای عمومی و خصوصی برای تعیین اعتبار توکن استفاده می کنه.

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

[lahij.ir]

سلام میدونم این بحث خیلی قدیمیه اما ایجاد یه موضوع جدید فکر نکنم کار خوبی باشه پس همینجا سوالم رو میپرسم
من کلیت موضوع jwt رو فهمیدم اما چند تا سوال مطرح میشه که میخواستم بدونم:
1- سرور توکن هارو کجا میتونه ذخیره کنه که امنیتش قابل قبول باشه؟
2- در صورتی که از کاربر درخواست احراز هویت شد سرور توکن دریافتی رو چطور بررسی میکنه ؟ میدونم که از secret key استفاده میشه ولی نحوه محاسبه و الگوریتمش رو متوجه نشدم
3- توکنی که سرور به کلاینت داده میشه کجا ذخیره بشه که امنیتش قابل قبول باشه؟ و اگه مثلا در کوکی ذخیره شده باشه با دزدیدن کوکی و ارسال درخواست با همون توکن توسط نفر دومی شدنی هست یا خیر سرور چطور میتونه این موضوع رو تشخیص بده؟
4- در صورتی که بخوایم کلا کوئری هایی که کلاینت از سرور میگیره رو کد گزاری کنیم و داخل توکن قرار بدیم و ارسال کنیم به کلاینت و در اونجا دیکد بشه و خروجی گرفته بشه jwt راه حل مناسبی هست یا خیر ؟ ( همزمان احراز هویت هم بشه مثل server api های مختلف که سرویس خاصی رو ارائه میدن )
ممنون میشم هر کس هر اطلاعاتی داره در این زمینه بنده رو راهنمایی کنه

[Nevercom]

اجازه بدین یه توضیح مختصری در مورد JWT بدم.

در این الگو، یک توکن ایجاد میشه که از سه بخش تشکیل شده، این سه قسمت با . (Dot) از هم جدا شدن. هرکدوم از این بخش ها جداگانه با Base64 انکود میشن

1. Header: در هدر اطلاعاتی مثل نوع توکن و الگوریتم کدگذاری نوشته شده
2. Payload: این قسمتی هست که همه ی اطلاعاتی که نیاز هست سرور و کلاینت بخوننش رو قرار میدید، مثلاً کد کاربر یا تاریخ انقضا توکن یا هر چیز دیگه
3. Signature: بخش سوم هم امضا هست. برای تولید امضا Header و Payload (که Base64 Encoded هستن) با . به هم وصل میشن و رشته ی نهایی با Secret Key که داریم و الگوریتمی که در هدر مشخص شده امضا میشه. این امضا برای این هست که در سرور مقایسه صورت بگیره و اصالت توکن بررسی بشه.

همونطور که مشخص هست، Header وPayload به راحتی قابل خوندن هستن و کافیه فقط Base64 Decode بشن

با این تفاسیر، سرور اصلاً توکن های تولید شده رو جایی ذخیره نمی کنه، فلسفه ش این هست که این مرحله حذف بشه و توکن هایی تولید بشن که بدون نیاز به چک کردن با دیتابیس، اصالتشون تایید بشه.

وقتی سرور توکن رو دریافت می کنه، یکبار دیگه اطلاعات رو Sign میکنه و Signature تولید شده رو با Signature موجود در Token مقایسه می کنه، اگر اینها یکی بودن یعنی توکن معتبر هست. چون در این روش از کلید خصوصی برای Sign/Verify استفاده میشه، مهمه که این کلید ترکیب رندومی از کاراکترها باشه و ازش حفاظت بشه.

در سمت کلاینت توکن باید ذخیره بشه، مثلاً در Cookie، مشخص هست که اون توکن خاص معرف یک کاربر خاص هست و اگر اون توکن ارسال بشه، سرور تشخیص میده که این درخواست از سمت اون کاربر خاص اومده، حالا اگر شخصی اون توکن رو از شما بدزده، و اون رو به سرور ارسال کنه، میتونه وارد اکانت شما بشه. اما موضوع این هست که اگر شخصی این دسترسی رو داشته باشه، دزدیدن یوزرنیم و پسورد شما هم میتونه به همون راحتی باشه.

اگر نیاز دارین میتونید تو Payload اطلاعات بیشتری مثل IP یا هر مشخصه ی دیگه رو هم بفرستید (که بعداً تو سرور این رو با IP درخواست دهنده مقایسه کنید)، اما اصلاً کمکی نمیکنه، چون تمام اطلاعاتی که از سمت کلاینت میاد میتونه جعلی باشه و هیچوقت، هیچوقت نباید به اطلاعاتی که از سمت کلاینت میاد اعتماد کرد.

اینکه چه اطلاعاتی رو در Payload میفرستید دست خودتون هست، اما توجه داشته باشید که این اطلاعات به راحتی قابل خوندن هستن

[lahij.ir]

بسیار عالی و ممنونم ازتون که توضیح دادین، فقط چندتا موضوع مشخص نیست
1- اینکه برای هر درخواست کلاینت سرور باید بررسی signature رو انجام بده؟ خوب در این صورت بار پردازشی بیشتر میشه منظورم اینه که ایجاد سیشن تو این الگوریتم چطور انجام میشه
2- بهتر نیست اطلاعات کلاینت ها داخل دیتابیس ذخیره بشه و طبق تاریخچه اطلاعاتی اونها و بررسیشون دسترسی و مجوز داده بشه ؟ به طور مثال ما در گوگل برای هر مرورگر سیشن جدا داریم و اگه هر کدوم از اطلاعات حتی ip از رنج مورد بررسی خارج باشه باید سیشن و احراز هویت جدا انجام بشه
3- در صورتی که داخل دیتابیس چیزی ذخیره نکنیم و صرفا با بررسی و محاسبه signature به کسی دسترسی بدیم admin و user بودن چطور بررسی میشه ؟ یا بهتره بگیم سطح دسترسی در این الگوریتم چطور انجام میشه و اینکه اگه ما برای کاربرانمون از یک secret key استفاده کنیم در صورت لو رفتن secret key امنیت کل کاربرها و حتی مدیرت به خطر می افته، این الگوریتم برای این موضوع ها چه کاری انجام میده؟

به طور کلی سوالم این هست که اگر ما از اصول این الگوریتم استفاده کنیم ولی مواردی رو بهش اضافه کنیم مثل ذخیره اطلاعات در دیتابیس و در نظر گرفتن key public و secret key private برای هر درخواست و ایجاد سیشن سمت سرور و ... به خود الگوریتم و ساختارش ضربه وارد میشه ؟ ( چه از نظر مفهومی چه از نظر امنیتی ) از اینکه همراهی میکنید ممنونم

[Nevercom]

هیچ Sessionی وجود نداره، این توکن همون کار Session رو انجام میده، فقط بجای اینکه مسيولیتش بیفته گردن پلتفرمی که ازش استفاده می کنید، خودتون مدیریتش می کنید.

بله، برای هر درخواست این بررسی انجام میشه، یعنی وقتی شما سیستم Token-Based طراحی می کنید، همیشه نوعی از بررسی رو روی این توکن در هر درخواست انجام میدید.
اصولاً باید بر اساس نیازهایی که پروژه تون داره، راه حل مناسب رو انتخاب کنید، هیچ روشی در دنیای برنامه نویسی وجود نداره که برای همه ی حالت ها و کاربردها، بهترین انتخاب باشه.

با یه مثال واقعی کاربرد این الگو مشخص تر میشه.
مسئولیت اصلی من توسعه ی APIهایی هست که اجازه ی ارتباط با سرور رو به کلاینت ها میده (برنامه نویسی Backend)، ایده ی من این هست که این API هسته ای رو شکل میده که کلاینت ها باهاش ارتباط برقرار می کنن، و تفاوتی نداره که این کلاینت یک برنامه ی اندرویدی هست یا مرورگر. یعنی با همین API باید بشه وب سایت رو طراحی کرد، برنامه ی Android, iOS و...رو هم طراحی کرد.

در این حالت برای احراز هویت من به سمت Token میرم. همونطور که میدونید درخواست های Http حالت Stateless دارن، یعنی در این پروتوکل خصوصیتی وجود نداره که درخواست اول یک کاربر رو به درخواست دوم کاربر ارتباط بده تا سرور متوجه بشه اینها همه از طرف یک کابر واحد میان (بین درخواست اول و دوم میتونه از چند میلی ثانیه تا چند قرن فاصله ی زمانی وجود داشته باشه). Session برای همین منظور ایجاد شده، درواقع سشن واسطه ای هست تا درخواست های یک کاربر در یک بازه ی زمانی مشخص رو به هم ارتباط بده، برای اینکار هم یک id (درواقع یک توکن) تولید می کنه که وظیفه ی ارتباز درخواست ها به هم رو به عهده میگیره، و برای استفاده از این قابلیت یک استانداردی تعریف شده که سرور و کلاینت ها باهاش آشنا هستن. با توجه به اینکه استانداردهای وب در این چند دهه خیلی تغییر کرده، من ترجیح میدم از Session فاصله بگیرم و پیاده سازی متفاوتی برای این منظور داشته باشم تا بهینه تر و توسعه پذیرتر باشه.

اگر یک سیستم اینچنینی رو طراحی کرده باشید، میدونید که دیتابیس قلب سیستم هست و بیشتر از هر بخش دیگه منابع مصرف می کنه و باید ازش مراقبت بشه. در سرور یکی از منابع مهم و پر مصرف رم هست و CPU در خیلی از موارد ازش کار کشیده نمیشه. و مهمترین مصرف کننده ی رم هم همین دیتابیس هست. مثلاً اگر دیتابیس و اپلیکیشن همه روی یک سرور قرار داشته باشن، شاید تا ۸۵ درصد از رم در اختیار دیتابیس قرار داده میشه.

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

اگر من APIی داشته باشم که تعداد زیادی مصرف کننده داشته باشه (مثلاً فرض کنید سرویسی مثل Parse یا Firebase یا Instagram رو میخواید طراحی کنید)، و نیاز به نوعی احراز هویت داشته باشم، ترجیح من این هست که درخواست های دیتابیسی رو برای بخش های مهم تر نگه دارم. JWT اینجا برای من کاربرد داره، یک توکن ایجاد میشه که بدون نیاز به ثبت در دیتابیس، میشه اصالتش رو تایید کرد و درون همین توکن همه ی اطلاعات موردنیازمون رو ذخیره کنیم.

میدونید که برای استفاده از این توکن ها، درصورتی که در دیتابیس پیاده سازی بشه، نیاز به ذخیره ی اطلاعات دیگری کنار همین توکن دارید، مثلاً کد کاربر، دسترسی های کاربر، تاریخ اعتبار توکن و هر اطلاعات دیگه ای که اپلیکیشن شما نیاز داشته باشه. ذخیره اینها در دیتابیس هم منابع بیشتری از سیستم میگیره. در JWT میشه همه ی این اطلاعات رو در خود توکن ذخیره کرد و هیچ محدودیتی هم ندارید، برخلاف دیتابیس که به هرحال همیشه محدودیت ها و ملاحظاتی در تعداد فیلد های جداولمون داریم.

تا به اینجای کار با JWT تونستم در مرحله Authentication فشار رو از دوش دیتابیس بردارم و بیارمش سمت اپلیکیشن (یعنی به ازای هر درخواست حداقل یک Database Trip کمتر دارم) که برای من بهینه سازی سیستم محسوب میشه. مسلماً در حالتی که این اطلاعات در دیتابیس ذخیره نمیشه، من نمیتونم آنالیزی روی اونها انجام بدم، پس اگر اپلیکیشن من نیاز به این آنالیزها داره (مثلاً اینکه هر کاربر آخرین بار چه زمانی لاگین کرده) یا باید JWT رو کنار بزارم و یا اینکه با بررسی دو سیستم، اگر استفاده از JWT در کنار دیتابیس باز هم بهتر از دیتابیس تنها هست،ترکیبی از اونها استفاده کنم (مثلاً درصورتی که دیتابیس تنها، به ازای هر درخواست ۳ Database Trip دارم و اگر JWT رو کنارش استفاده کنم میاد به ۱ DB Trip، خب باز هم استفاده ی ترکیبی بهتر هست).

موضوع بعدی این هست که چون توکن ها ذخیره نمیشن، پس در حالت عادی قابلیت Revoke رو نخواهیم داشت (مثلاً در حالتی که یک اکانت در چند مکان متفاوت مورد استفاده قرار میگیره و به دلیل اینکه ممکنه امنیت اکانتی به خطر افتاده باشه، بخوایم این توکن ها رو بی اعتبار کنیم تا مجبور به لاگین دوباره بشن)، در این حالت یا باید JWT رو کنار بزاریم یا اینکه با استفاده ی ترکیبی از دیتابیس و Caching Layer این قابلیت رو به سیستممون اضافه کنیم.

به هرعنوان تجربه ی من این هست که مراقبت و بهینه سازی دیتابیس پیچیدگی های خودش رو داره و بهتر هست که این بخش رو با درخواست های بیخود مشغول نکنیم.

در مورد سطح دسترسی و User یا Admin بودن هم هیچ تفاوتی در این دو روش وجود نداره، به هرحال باید این مشخصه ها در جایی نگهداری بشن، یا در دیتابیس و یا در خود توکن.

Secret Key باید ازش مراقبت بشه، اما احتمال لو رفتن این مورد بیشتر از لو رفتن اطلاعات اتصال به دیتابیس نیست (هر دو رو در کدهاتون استفاده می کنید)، اگر اطلاعات ورود به دیتابیس لو بره خطر خیلی جدی تری ما رو تهدید می کنه. مسلماً برای ایجاد سیستم های ایمن تر الگوریتم های خیلی بهتری وجود دارن که بنا به نیاز میشه ازشون بهره برد، اما در مقام مقایسه ی JWT و توکن مبتنی بر دیتابیس، از لحاظ امنیت در یک سطح قرار دارن.

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

[lahij.ir]

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