امنیت در کوکی [بایگانی]

bagherok

جمعه 25 مهر 1393, 23:10 عصر

سلام
فک میکنم
اگه دادها رو به هر صورت ممکن هم امن درون کوکی ذخیره کنیم باز امنیت برقرار نمیشه و
تنهاه را امنیت در کوکی جلوگیری از سرقت اون باشه

حالا چطوری میشه اینو پیاده کرد.

eshpilen

یک شنبه 27 مهر 1393, 09:22 صبح

نفهمیدم چی میگی.
درست و حسابی بیان کن بابا :لبخند:

aliphp1

یک شنبه 27 مهر 1393, 09:36 صبح

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

bagherok

یک شنبه 27 مهر 1393, 17:45 عصر

نفهمیدم چی میگی.
درست و حسابی بیان کن بابا http://barnamenevis.org/images/smilies/yahoo/109.gif
چشم:خجالت:

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

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

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

abolfazl-z

یک شنبه 27 مهر 1393, 23:32 عصر

bagherok

چهارشنبه 14 آبان 1393, 16:04 عصر

نگاه کنید ما سمت سرور اگر خودمان را هم بکشیم نمی توانیم امنیت را در سمت کلاینت تامیین کنیم !

درسته میتونیم ضرایب امنیتی را با برخی کار ها بالا ببریم ولی اگر امنیت کلاینت در هر صورت مورد خطر قرار بگیرد ما نمیتوانیم جلویش را بگیریم !

تو این تاپیک http://barnamenevis.org/showthread.php?413183-%D8%AC%D9%84%D9%88%DA%AF%DB%8C%D8%B1%DB%8C-%D8%A7%D8%B2-session-fixation
که یه سال پیش مطرح کردید
به نتیجه ای نرسید که بشه وقتی کوکی دست کسی دیگه افتاد نشه ازش استفاده ای کنه.
http://barnamenevis.org/showthread.php?413183-%D8%AC%D9%84%D9%88%DA%AF%DB%8C%D8%B1%DB%8C-%D8%A7%D8%B2-session-fixation&p=1845001&viewfull=1#post1845001

و این تاپیک ها از انجمن ایران php که رضا شیخله مطرح کرده(دقیقا یه همچین چیزی مدنظرم بود).
http://forum.iranphp.org/Thread-%D8%A8%D8%B1%D8%B1%D8%B3%DB%8C-%D9%88%D8%B6%D8%B9%DB%8C%D8%AA-%D9%84%D8%A7%DA%AF%DB%8C%D9%86-%D8%A8%D9%88%D8%AF%D9%86-%DA%A9%D8%A7%D8%B1%D8%A8%D8%B1-%D8%A8%D9%87-%D8%B1%D9%88%D8%B4-%D8%A7%D9%85%D9%86?pid=43390#pid43390

http://forum.iranphp.org/Thread-%D8%A8%D8%B1%D8%B1%D8%B3%DB%8C-%D9%88%D8%B6%D8%B9%DB%8C%D8%AA-%D9%84%D8%A7%DA%AF%DB%8C%D9%86-%D8%A8%D9%88%D8%AF%D9%86-%DA%A9%D8%A7%D8%B1%D8%A8%D8%B1-%D8%A8%D9%87-%D8%B1%D9%88%D8%B4-%D8%A7%D9%85%D9%86?pid=43403#pid43403

مثلا تو همین انجمن با گوگل کروم لاگین میکنم و تمام کوکی ها رو تو فایرفاکس ست میکنم با افزونه Advanced Cookie Manager
اما لاگین نمیکنه.
حالا نمیدونم از user agent استفاده کرده(هنوز تست نکردم )
یا راه دیگه ای رو

bagherok

چهارشنبه 14 آبان 1393, 23:15 عصر

نفهمیدم چی میگی.
درست و حسابی بیان کن بابا :لبخند:
سلام سیستم لاگین شما رو هم تست کردم
با فرض اینکه مقادیر کوکی ها رو بشه سرقت کرد میشه لاگین کرد.
سیستم لاگین نصب کردم
لوکال
روی xampp
بعد با portforwarding
آنلاینش کردم.
و بعد با ای پی اینترنتی(نه لوکال) وارد سیستم شدم
و مقادیری رو که یکی ازدوستام از سیستم خودش لاگین کرده بود
و برام فرستاده بود
لاگین کردم
لاگین شد.

نسخه مرورگرمون یکی بود ولی نسخه ویندوزم 7
و واسه اون8

حالا با ست کردن httponly میشه جلوی سرقت کوکی رو گرفت!!!

اگه کارم ازابتدا اشتباست ممنون میشم متذکربشید.

عکس رو هم ضمیمه کردم

eshpilen

پنج شنبه 15 آبان 1393, 07:52 صبح

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

abolfazl-z

پنج شنبه 15 آبان 1393, 12:10 عصر

تو این تاپیک http://barnamenevis.org/showthread.p...ssion-fixation (http://barnamenevis.org/showthread.php?413183-%D8%AC%D9%84%D9%88%DA%AF%DB%8C%D8%B1%DB%8C-%D8%A7%D8%B2-session-fixation)
که یه سال پیش مطرح کردید
به نتیجه ای نرسید که بشه وقتی کوکی دست کسی دیگه افتاد نشه ازش استفاده ای کنه.
http://barnamenevis.org/showthread.p...=1#post1845001 (http://barnamenevis.org/showthread.php?413183-%D8%AC%D9%84%D9%88%DA%AF%DB%8C%D8%B1%DB%8C-%D8%A7%D8%B2-session-fixation&p=1845001&viewfull=1#post1845001)

درواقع session fixation همان سرقت سشن رو عنوان میکند.

از دید من امنیت صفحه ورود تنها به سشن یا کوکی ختم نمیشه !

امنیت هنگام ورود

مثلا بانک ملت به ازای هر ورود کاربرانش به سیستم یک پیام به گوشی آن ها sms می کند که در واقع کاربر خاطر اش از این باب جمع هست که کسی وارد سیستم بشه می تونه متوجه بشود ولی این کار خودش نقص هایی از دید من داره، برفرض مثال کسی بجای ما وارد سایت شد و ما فهمیدیم ولی جایی مناسبی نیستیم که سریع به بانک یا اینترنتی دسترسی داشته باشیم اون وقت چی ؟ تا اون لجظه ایی که ما بخواهیم کاری کنیم اون کار خودشو انجام داده ! ولی اگر مثلا میامد به همراه همان اس ام اس یک کدی می گذاشت که باعث غیرفعال سازی سیستم می شد تا کاربر به بانک مراجعه کند. (یعنی اون کد را به همان شماره sms میکرد) یا مثلا به ازای هر لاگین یک کدی به گوشی طرف می فرستاد و طرف اون رو در سایت یا دوباره به همان شماره اس میکرد و عملایت لاگین انجام می شد.(این برای زمانی خوب هست که طرف به گوشی اش هم دسترسی نداره)

یا اگر امنیت سیستم، نسبت به بانک اهمیت چندانی ندارد بجای sms از email استفاده بشود و ...
خوب باز هم نواقض می تونه وجود داشته باشد و بر فرض مثال بگیم طرف گوشی کاربر هم داشته باشه (دیگه بانک میگه حرف بزنی میزنمت:لبخند:)

امنیت هنگام تبادل اطلاعات

سرقت سشن توسط اشتباه برنامه نویس :

اگر اسکرییپتی که می نویسیم از لحاظ امنیتی مشکلی داشته باشه میتونه راه را برای حمله کننده باز کند و سشن را به سرقت ببرد. باگ هایی نظیر sql injection ، xss و ...

سرقت سشن توسط حمله مرد میانی :

خوب این حمله که یکی از متداول ترین نوع حمله هست که می توینم از پروتکل امن ssl استفاده کنیم.

http://fa.wikipedia.org/wiki/%D8%AD%D9%85%D9%84%D9%87_%D9%85%D8%B1%D8%AF_%D9%85 %DB%8C%D8%A7%D9%86%DB%8C

سرقت سشن توسط اشتباه کاربر :

اشتباه کاربر را میشه کلی در نظر گرفت.

مثلا در سیستم های بانکی نباید رمز ات را همراه کارت ات بگذاری
و همچنین در سیستم کاربر باید حداقل یک آنتی ویروس قوی نصب باشه
و یا از v_p_n های معتبر استفاده کند
و یا اینکه سیستم اش را در اختیار هر کسی قرار ندهد (بخصوص لپتاپ ها)
و همچنین همیشه نرم افزاری هایی نظیر آنتی ویروس و مروگر باید بروز بشوند
و ...

خوب حالا به نظر خودتون ما امنیت هنگام ورود و امنیت هنگام تبادل اطلاعات(سرقت سشن توسط اشتباه برنامه نویس - سرقت سشن توسط حمله مرد میانی) را کامل رعایت کردیم و امنیت کامل برقرار شد.

اگر کاربر اشتباه کند چی ؟ می توانید جلویش را بگیرید ؟

خوب البته این کار هم میشه انجام داد ولی دیگه خیلی محدود میشیم و از نظر من این کار باز خودش دردسر هایی امنیتی را هم به دنبال داره !

[ویرایش :]

درضمن این رو هم فراموش کردم بگم که اصلا ممکن هست یک اشتباهی از سرویس دهنده هاست به عمل بیاید.
و همچنین ممکن هست باگ هایی خطرناک نیز در این عمل نقش داشته باشند. (باگ خونریزی قلبی (http://heartbleed.com/))
اگر چنین مورد هایی رخ دهد باعث نقض امنیت می شود !

bagherok

پنج شنبه 15 آبان 1393, 14:31 عصر

درواقع session fixation همان سرقت سشن رو عنوان میکند.

از دید من امنیت صفحه ورود تنها به سشن یا کوکی ختم نمیشه !

بله درست میگید
و غیر این هم نیست.
اما درمورد این قسمت از کار زوم کردم.

به فرض اینکه تمام نکات امنیتی لحاظ شده باشه
اما نمیخوام کوکی ها قابل سرقت باشه.

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

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

درهرصورت ممنون از توجهتون.

eshpilen

پنج شنبه 15 آبان 1393, 18:25 عصر

نمیشه!
البته با روشهای پیچیده ای شاید بشه کاری کرد (مثلا استفاده از توکن های سخت افزاری)، ولی چیزی نیست که بشه برای سایتها و موارد عادی استفاده کرد.

abolfazl-z

پنج شنبه 15 آبان 1393, 22:42 عصر

نمیشه!
البته با روشهای پیچیده ای شاید بشه کاری کرد (مثلا استفاده از توکن های سخت افزاری)، ولی چیزی نیست که بشه برای سایتها و موارد عادی استفاده کرد.

آره خیلی عالی هست.

ولی برای کاربر نمیشه ولی برای مدیریت میشه

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

البته من هیچ تجربه ایی در این باب ندارم (desktop application).

اما ایده ایی که دارم این هست که یک نرم افزار سیستمی که متعلق فقط به یک کاربر میشه (هر کاربر یک نرم افزار در خصوص سیستم خود )و کاربر هر وقت که بخواهد به سایت وصل شود نرم افزار نام کاربری و رمز عبور را بصورت کاملا امن گرفته و ...

البته نمیدونم میشه یا نمیشه !

bagherok

پنج شنبه 15 آبان 1393, 22:45 عصر

نمیشه!
البته با روشهای پیچیده ای شاید بشه کاری کرد (مثلا استفاده از توکن های سخت افزاری)، ولی چیزی نیست که بشه برای سایتها و موارد عادی استفاده کرد.
بیشتر توضیح بدید.

یکی از اون روشها این نیست که بیایم پلاگین هایی رو که رو مرورگر نصب هست رو درون کوکی قرار بدیدم!
یا فونت های نصب شده

مثلا این لینک رو ببینید
اطلاعات کاملی از یه کاربر میده
https://panopticlick.eff.org/index.php?action=log&js=yes

eshpilen

جمعه 16 آبان 1393, 12:17 عصر

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

البته من هیچ تجربه ایی در این باب ندارم (desktop application).

اما ایده ایی که دارم این هست که یک نرم افزار سیستمی که متعلق فقط به یک کاربر میشه (هر کاربر یک نرم افزار در خصوص سیستم خود )و کاربر هر وقت که بخواهد به سایت وصل شود نرم افزار نام کاربری و رمز عبور را بصورت کاملا امن گرفته و ...

این نرم افزار هم بهرحال روی سیستم کاربر هست و امنیت اصولیش در حد بقیه چیزها در سمت کلاینت. ممکنه سرقت بشه و مهندسی معکوس و کرک بشه.
اگر هم برای رمزنگاری اطلاعات از کلاینت تا سرور و بعکس روشی میخواید، خب SSL/TLS واسه همینه و این همه دردسر اضافی رو هم نداره و کاربر مجبور نیست بخاطر استفاده از سایت شما بهتون اعتماد دربست داشته باشه و روی سیستمش برنامهء شما رو نصب کنه (که میتونه براحتی جاسوسی کنه و غیره).

اون توکن های سخت افزاری هم که گفتم مثلا یه چیزایی هستن مثل cool/flash disk که وصل میکنی به USB سیستم، و البته انواع و شکلها و روشهای دیگری هم میتونن داشته باشن (بعضیا حتی به سیستم هم وصل نمیشن و مثلا هر بار بهت یک کد/رمز یک بار مصرف میدن برای یک لاگین)، بخاطر این گفتم چون قبلا راجع بهشون مطالعه کردم و ظاهرا میشه جوری درستشون کرد که کپی کردن اونا به این راحتی ها شدنی نباشه.

البته بهرصورت وقتی شما از هر نوع توکن استفاده میکنید میشه two factor authentication که امنیتش از حالت عادی بیشتره (ولی بازم بنظر شخص بنده میزان افزایش امنیت میان انواع مختلفش میتونه تفاوت زیادی داشته باشه، چون بعضی روشها رو میشه نسبتا راحت شکست داد و بعضیا رو به این سادگی نمیشه).
two factor authentication اشاره به این داره که دو فاکتور برای احراز هویت کاربر، همزمان وجود داره/نیاز است. یکی چیزی که کاربر میداند (پسورد)، و دیگری چیزی که کاربر دارد (توکن سخت افزاری بطور مثال). ولی در احراز هویت معمولی فقط مبتنی بر پسورد ما تنها یک فاکتور داریم (چیزی که کاربر میداند) و حتی اگر 10 تا پسورد هم بذاریم بازم two factor authentication نمیشه و امنیتش به اون نمیرسه.

البته گمونم افزودن desktop application هم که شما گفتید اگر به شکلهای خاصی طراحی و پیاده سازی بشه two factor authentication حساب کرد، ولی گفتم که یکسری مشکلاتی داره و ضمنا آنچنان شکست ناپذیر هم نیست. بنابراین فکر نمیکنم ارزشش رو داشته باشه، مگر چی باشه به چه دلیلی و کاربردهای خیلی خاصی، که اونم نمیدونم چرا از توکن ها و روشهای استانداردی که هست بجاش استفاده نکنیم اگر کاربرد خیلی حساس است و میخوایم امنیت سمت کلاینت رو هم به حداکثر ممکن برسونیم.

eshpilen

جمعه 16 آبان 1393, 12:41 عصر

بیشتر توضیح بدید.

یکی از اون روشها این نیست که بیایم پلاگین هایی رو که رو مرورگر نصب هست رو درون کوکی قرار بدیدم!
یا فونت های نصب شده

مثلا این لینک رو ببینید
اطلاعات کاملی از یه کاربر میده
https://panopticlick.eff.org/index.php?action=log&js=yes

شاید بشه اینم جزو two factor authentication حساب کرد، ولی بنظرم یه مشکلات و ضعفهایی داره. مثلا اینکه مقدار آنتروپی این اطلاعات خیلی زیاد نیست و در بعضی شرایط میتونه خیلی کم یا در حد صفر باشه. فرض کنید مثلا این روش چون مبتنی بر خود مرورگر است و تقریبا/احتمالا جزیی درونی و ثابت از یک PC، و نه لزوما فقط یک کاربر خاص، بنابراین هرکس که از اون سیستم استفاده کنه این عامل رو با دیگران مشترکه، و این باعث میشه امنیت پایین بیاد. در two factor authentication کاربر یک چیزی داره که اغلب قابل جابجاییه و لزوما جزیی ثابت و به اشتراک گذاشته شده از یک PC نیست (هرچند اگر بخوایم احتمالا میشه اون رو به یک PC خاص هم وابسته کرد). مثلا یک USB token رو میشه براحتی جدا کرد، در جیب گذاشت، جای دیگه برد، در گاوصندوق گذاشت، در محیط کار/پیش رئیس باقی بمونه، و غیره، که مثلا خلافکارها یکی رو بگیرن که مسئول یک سیستم خیلی مهمه و حتی کتکش هم بزنن شکنجه هم بکنن بگن پسورد رو بده اغلب فایده نداره چون بدون توکن کسی نمیتونه وارد بشه و پسورد به تنهایی کافی نیست. پس میبینید که قصد از فاکتور دوم در احراز هویت چیه و چقدر انعطاف و امنیت کار رو بالا میبره و میتونه سناریوهای خیلی بیشتر رو پوشش بده. اما روشی که شما میگید اینقدر امنیت و انعطاف نداره (گرچه طبیعتا میتونه امنیت رو تا یک حدی بالا ببره). ضمنا این اطلاعات همش اطلاعاتیه که هکر اگر روی سیستم کلاینت نفوذ کرده باشه و بتونه مثلا کوکی های احراز هویت رو بخونه میتونه این اطلاعات رو هم بخونه و جعل این موارد برای یک هکر باسواد و با انگیزه هم کار چندان سختی نیست بنظرم! حتی در موارد دیگری که دسترسی روی کلاینت بدست نیاورده ولی از طریق همون کانال ناامن HTTP هم میتونه کم و بیش به این اطلاعات دسترسی پیدا کنه حالا اینکه تا چه حد و چقدر راحت یا سخت و جلوی چه انواعی از هکرها و حمله ها رو بگیره و نگیره (مثلا انواع Passive و Active) خودش داستان داره و بستگی به اینکه شما این سیستم رو چطور طراحی کرده باشید هم داره، ولی در کل بهرحال روزهء شک داره و فکر نمیکنم با توجه به مشکلات و محدودیت هایی هم که داره ارزش این همه پیچیدگی و تحلیل و کار اضافه رو داشته باشه.

تاجاییکه میدونم این قضیهء browser fingerprint بیشتر کاربردش در موارد دیگری هست و برای ردیابی یک کلاینت خاص استفاده میشه (که درجهء اهمیت حیاتی نداره) و برای کارهای امنیتی و موقعی که کسی میخواد به کلاینت حمله کنه و این حرفا بنظر نمیاد که روش اصولی ای باشه، هرچند گفتم که میشه استفاده کرد و میتونه امنیت رو هم بالا ببره ولی در کل روش جالبی بنظر نمیاد و فکر نمیکنم ارزشش رو به هیچ وجه داشته باشه و بیخودی اینقدر سیستم رو پیچیده و نامنعطف بکنیم که میتونه مشکلاتی از دید کاربری هم ایجاد بکنه (مثلا اومدیم کاربر یک پلاگینش رو تغییر داد یا آپدیت شد و امثالهم که شاید حتی الان به فکر من و شما نرسه - بهرحال ما کلی پارامتر جدید رو وارد برنامه کردیم که باید تمام سناریوها و مسائل مربوط به اونا رو بدونیم تا بتونیم مطمئن بشیم که چه مسائلی با چه احتمالی میتونن پیش بیان این وسط).

بیایم پلاگین هایی رو که رو مرورگر نصب هست رو درون کوکی قرار بدیدم!
توی کوکی قرار بدی که دیگه چه فرقی میکنه با بقیهء کوکی ها خب اینم به همون راحتی قابل سرقت و جعل میشه!
این اطلاعات رو توی کوکی قرار نمیدن (یا فقط توی کوکی قرار نمیدن)، بلکه با جاوااسکریپت و این حرفا سمت کلاینت چک میکنن (و البته یکسری مثل User agent هم که بصورت خودکار به سمت سرور ارسال میشن در هر درخواست) و سمت سرور هم نتیجه بررسی میشه.

abolfazl-z

جمعه 16 آبان 1393, 14:51 عصر

این نرم افزار هم بهرحال روی سیستم کاربر هست و امنیت اصولیش در حد بقیه چیزها در سمت کلاینت. ممکنه سرقت بشه و مهندسی معکوس و کرک بشه.

هر نرم افزاری منحنی شکست دارد.

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

ssl/tls فقط امنیت بین راه را تامین می کند ولی ما می خواهیم با نصب نرم افزار شخصی علاوه بر امنیت بین راه ، مسائل امنیتی دیگر را نیز رعایت کنیم البته نمیگم به این سادگی میشه یک نرم افزار نوشت داد بیرون که هر کی بتونه استفاده کنه

بلکه باید در حد یک آنتی ویروس قدرت کافی داشته باشه نه برای حفاظت سیستم بلکه برای حفاظت اطلاعات خودش. پس یعنی این نرم افزار یک برنامه نویس کاملا مسلط را می طلبد.

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

اون توکن های سخت افزاری هم که گفتم مثلا یه چیزایی هستن مثل cool/flash disk که وصل میکنی به USB سیستم، و البته انواع و شکلها و روشهای دیگری هم میتونن داشته باشن (بعضیا حتی به سیستم هم وصل نمیشن و مثلا هر بار بهت یک کد/رمز یک بار مصرف میدن برای یک لاگین)، بخاطر این گفتم چون قبلا راجع بهشون مطالعه کردم و ظاهرا میشه جوری درستشون کرد که کپی کردن اونا به این راحتی ها شدنی نباشه.

البته بهرصورت وقتی شما از هر نوع توکن استفاده میکنید میشه two factor authentication که امنیتش از حالت عادی بیشتره (ولی بازم بنظر شخص بنده میزان افزایش امنیت میان انواع مختلفش میتونه تفاوت زیادی داشته باشه، چون بعضی روشها رو میشه نسبتا راحت شکست داد و بعضیا رو به این سادگی نمیشه).
two factor authentication اشاره به این داره که دو فاکتور برای احراز هویت کاربر، همزمان وجود داره/نیاز است. یکی چیزی که کاربر میداند (پسورد)، و دیگری چیزی که کاربر دارد (توکن سخت افزاری بطور مثال). ولی در احراز هویت معمولی فقط مبتنی بر پسورد ما تنها یک فاکتور داریم (چیزی که کاربر میداند) و حتی اگر 10 تا پسورد هم بذاریم بازم two factor authentication نمیشه و امنیتش به اون نمیرسه.

البته گمونم افزودن desktop application هم که شما گفتید اگر به شکلهای خاصی طراحی و پیاده سازی بشه two factor authentication حساب کرد، ولی گفتم که یکسری مشکلاتی داره و ضمنا آنچنان شکست ناپذیر هم نیست. بنابراین فکر نمیکنم ارزشش رو داشته باشه، مگر چی باشه به چه دلیلی و کاربردهای خیلی خاصی، که اونم نمیدونم چرا از توکن ها و روشهای استانداردی که هست بجاش استفاده نکنیم اگر کاربرد خیلی حساس است و میخوایم امنیت سمت کلاینت رو هم به حداکثر ممکن برسونیم.

درواقع یعنی یک توکن سخت افزاری ایجاد میشه و از آسیب های نرم افزاری در امان هست و مستقل از platform نیست درسته ؟ یعنی اگر ویندوز باشه باید بوسیله ویندوز یک سری کار ها را انجام دهد ولی توکن اش رو خودش سخت افزاری درست میکنه

پس اطلاعات را از سیستم به سرور می فرستد ؟ آیا این اطلاعاتی که می فرستد توسط نرم افزار سیستمی قایل ردیابی نیستند ؟ برای رد و بدل کردن اطلاعات از رمز نگاری هایی که در ssl استفاده شده، استفاده می کند ؟

bagherok

جمعه 16 آبان 1393, 14:58 عصر

eshpilen

جمعه 16 آبان 1393, 18:49 عصر

هر نرم افزاری منحنی شکست دارد.
بابا سطح دیپلم صحبت کن ما هم بفهمیم :لبخند:

عرضم به حضورت که بعضی منحنی شکست ها کم و بیش ثابته در طول زمان و شرایط متداول، ولی بعضیا که بر اساس حدسیات و تصورات و فرضهای تضمین نشده و روشهای غیراصولی بنا شدن اینطور نیستن و میتونن خیلی ناپایدار و غیرقابل پیشبینی باشن. مثلا میبینی یه سیستمی اینچنین که فراگیر میشه و بقدر کافی اهمیت پیدا میکنه و دو نفر آدم با سواد انگیزه کافی پیدا میکنن که روش وقت و مایه بذارن اونوقت دخلش رو میارن (و ممکنه روش و برنامه و تشکیلات دست عموم هم بیفته) بطوریکه دیگه تا قیام قیامت هم لکهء ننگش بر دامان بشریت باقی میمونه و کمتر کسی حاضر میشه ازش استفاده کنه!!

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

ssl/tls فقط امنیت بین راه را تامین می کند ولی ما می خواهیم با نصب نرم افزار شخصی علاوه بر امنیت بین راه ، مسائل امنیتی دیگر را نیز رعایت کنیم البته نمیگم به این سادگی میشه یک نرم افزار نوشت داد بیرون که هر کی بتونه استفاده کنه

بلکه باید در حد یک آنتی ویروس قدرت کافی داشته باشه نه برای حفاظت سیستم بلکه برای حفاظت اطلاعات خودش. پس یعنی این نرم افزار یک برنامه نویس کاملا مسلط را می طلبد.

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

درواقع یعنی یک توکن سخت افزاری ایجاد میشه و از آسیب های نرم افزاری در امان هست و مستقل از platform نیست درسته ؟ یعنی اگر ویندوز باشه باید بوسیله ویندوز یک سری کار ها را انجام دهد ولی توکن اش رو خودش سخت افزاری درست میکنه

پس اطلاعات را از سیستم به سرور می فرستد ؟ آیا این اطلاعاتی که می فرستد توسط نرم افزار سیستمی قایل ردیابی نیستند ؟ برای رد و بدل کردن اطلاعات از رمز نگاری هایی که در ssl استفاده شده، استفاده می کند ؟
جزییاتش یادم نیست و مطمئن نیستم. اینطور چیزها مسائل ظریف و پیچیده زیاد داره و انواع متعدد هم داره و به روشهای رمزنگاری پیشرفته هم میتونه مرتبط باشه که تحلیل ذهنی همهء اینا کار ساده و سریعی نیست. من خودم الان حضور ذهن کافی ندارم و با اینه مقاله و مطلب در این مورد خوندم فقط یکسری چیزها و ایده های شبح وار کلی توی ذهنم میتونم تصور کنم.
یکسری توکن هایی که من طرز کارشون رو خوندم مربوط به جلوگیری از کرک و استفاده غیرمجاز از نرم افزار میشدن که مطمئن نیستم طرز کار اونا رو تا چه حد میشه در فیلد امنیت مورد نظر ما هم ربط داد و استفاده کرد. مثلا بخشی اساسی از نرم افزار داخل توکن سخت افزاری هست که بخش دیگر نرم افزار که روی PC اجرا میشه ممکنه داده ها رو به توکن سخت افزاری بفرسته و بخشی از پردازش و کار برنامه توسط توکن صورت بگیره؛ یعنی درواقع بخشی از برنامه/الگوریتم داخل توکن است و جای دیگری نیست. شاید در بعضی موارد هم شاید برنامه بصورت دینامیک این کدها رو از توکن بیرون بکشه و بیاره روی خود PC اجرا کنه (که البته طبیعتا این امنیتش کمتره). ضمنا بنظرم این توکن ها در درجهء سختی ای که قابل کپی کردن هستن تفاوت میکنن؛ طبیعتا اونایی که اختصاصا برای محافظت در برابر کپی و دسترسی غیرمجاز و مهندسی معکوس ساخته شدن امن تر (و البته معمولا گران تر و مشکل تر برای تولید) هستن. البته روشهای دیگری هم وجود داره طبیعتا، مثلا اینکه نرم افزار اصلی فقط وجود و کلیدهای رمزنگاری موجود در یک توکن رو چک بکنه، که بنظرم امنیتش از توکن های فعال/پردازنده کمتره، و باز این خودش میتونه انواع داشته باشه مثلا یکسری در برابر کپی و مهندسی معکوس مقاوم هستن و یکسری نیستن یا کمتره. و بعدم اینطور نیست فکر کنید مثلا یک توکن که وصل میشه به USB لزوما طبق پروتکل های استاندارد و مثل cool disk های معمولی کار میکنه و به اون شکل قابل استفاده است، ولی بعضیا هم اینطور هستن.
خلاصه این بحث انواع توکن خودش یجورایی یه زیرشاخه و تخصص میشه واسه خودش. یه بخشی ازش هم باز به علم رمزنگاری ارتباط داره و کسی که میخواد اینطور توکن ها و سیستمهای امن و مقاوم رو طراحی بکنه باید تخصص کافی در علم رمزنگاری هم داشته باشه، ولی طبیعتا یکسری روشهای کمتر پیچیده و کمتر امن هم وجود دارن که شاید افراد عادی تر هم بتونن درست کنن که بهرحال اونم میتونه امنیت رو به میزان زیادی بالا ببره ولی نه لزوما همیشه و برای همه کار و همه شرایطی.

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

eshpilen

جمعه 16 آبان 1393, 19:06 عصر

قفل سخت افزاری یا همون توکن امنیتی که میگید برای مقاصد خاص دیگه است
و هدفم ساخت یه توکن امنیتی بصورت نرم افزاری و با همین منابع محدود است.
پیچیدگی خاصی هم نداره که میگید.
اینجا رو ببیند http://valve.github.io/fingerprintjs/
یه fingerprint به مرورگر و pc شما اختصاص میده که تقریبا میتونه به معنی واقعی اثر انگشت باشه.

یه عدد بزرگی که جعلش سخت هست.
مثلا باید تمام پلاگین های که رو سیستم نصب هست رو نصب داشته باشه (!)
و برای امنیت بیشتر رندوم یه سری از پلاگین ها رو بصورت هش شده درون کوکی قرار میدیم یا هم درون دیتابیس (یه جایی باید ذخیره شه خب)
اینجوری کار خیلی براش سخت میشه. درضمن قرارنیست که کاربرتا ابد توسایت لاگین بمونه که با تغییر پلاگین یا آپدیت و امثالهم... مشکلی پیش بیاد.
ولو اینکه با پاک کردن کوکی ها هم همچین اتفاقی میافته.

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

ضمنا با کلی گویی های کم و بیش مبهم هم نمیشه بیش از این پیش رفت و برای تحلیل و قضاوت بیشتر باید تمام الگوریتم کامل و دقیق مورد نظر خودتون رو بصورت یک مثال کلی (احتمالا همراه شبه کدی چیزی) درج کنید تا بعد دیگران بتونن منظور شما رو دقیقا متوجه بشن و دربارش نظر بدن و ضعف ها و اشکالاتش رو بگن. بنابراین اگر ایده ای دارید و میخواید بیش از این روش بحث بشه، باید اینطور عمل کنید. بعنوان مثال میگید کاربر که لاگین میکنه 1- ما میایم اطلاعات پلاگین های نصب شده روی مرورگرش رو میریزیم توی دیتابیس (البته درواقع این اطلاعات رو میچسبونن بهم و هش میکنن که اینطوری فشرده میشه) 2- در هر درخواست میایم دوباره این اطلاعات رو از طریق جاوااسکریپت در سمت کلاینت میخونیم و با مقدار موجود در دیتابیس مقایسه میکنیم ... و خلاصه اینطوری! با همین دو خط که من الان گفتم میشه ثابت کرد که امنیت اصولی نداره!! ضمنا اصلا اون مورد کوکی هم که شما میگید متوجه نشدم دقیقا چطوری و کجاش کاربرد داره.

bagherok

جمعه 16 آبان 1393, 23:18 عصر

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

ضمنا با کلی گویی های کم و بیش مبهم هم نمیشه بیش از این پیش رفت و برای تحلیل و قضاوت بیشتر باید تمام الگوریتم کامل و دقیق مورد نظر خودتون رو بصورت یک مثال کلی (احتمالا همراه شبه کدی چیزی) درج کنید تا بعد دیگران بتونن منظور شما رو دقیقا متوجه بشن و دربارش نظر بدن و ضعف ها و اشکالاتش رو بگن. بنابراین اگر ایده ای دارید و میخواید بیش از این روش بحث بشه، باید اینطور عمل کنید. بعنوان مثال میگید کاربر که لاگین میکنه 1- ما میایم اطلاعات پلاگین های نصب شده روی مرورگرش رو میریزیم توی دیتابیس (البته درواقع این اطلاعات رو میچسبونن بهم و هش میکنن که اینطوری فشرده میشه) 2- در هر درخواست میایم دوباره این اطلاعات رو از طریق جاوااسکریپت در سمت کلاینت میخونیم و با مقدار موجود در دیتابیس مقایسه میکنیم ... و خلاصه اینطوری! با همین دو خط که من الان گفتم میشه ثابت کرد که امنیت اصولی نداره!! ضمنا اصلا اون مورد کوکی هم که شما میگید متوجه نشدم دقیقا چطوری و کجاش کاربرد داره.

نه اصلا اینجوری فک نمیکنم.
اگه اینطوری فک میکردم که به خودم این همه سختی نمیدادم که!!!

خوب مشکل همینجاست.
من اینطوری فک میکنم که
ما یه کلید یا همون کوکی رو میسازیم و میگیم که بعد هرکی با این کلید وارد سایت شد لاگینه
حالا بگیم که درسته کلید یا کوکی رو داری
اما ببینم واقعا این کلید متعلق به تو هست یا نه یا دزدیش!!!(البته که ما اینجا با مرورگر کار داریم ونه کاربر)

خوب حالا میایم اطلاعات زیر رو بصورت md5 درمیاریم.
// * the user agent
// * screen size
// * color depth
// * the timezone offset
// * sessionStorage support
// * localStorage support
// * the list of all installed plugins (we're using their names,descriptions, mime types and file name extensions here)

مثل خروجی زیر رو تولید کنه

7d182ededf47c9c4b331edbf9d7e2896

وقتی کاربر لاگین میکنه این هش رو درون سشن قرار میدیم
و دردفعات بعدی میایم دوباره اینکار رو انجام میدیم و اینبار با این سشن مقایسه میکنیم
اگه برابر بود لاگین میومنه
نبودم که نبود:متعجب:

( نمیدونم چه گیری داده بودم به اینکه باید حتما درون کوکی ذخیر شه.درحالی که باید از سشن استفاده بشه )

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

( البته تو کد پایین همه اطلاعات مرورگر هش شده و فقط قسمت اول رو پیاده سازی کرده.یعنی هش کردن تمام اطلاعاتی که مرورگر میده )

به عنوان نمونه میتونید
http://github.com/carlo/jquery-browser-fingerprint
اینجا رو ببیند
یا فایلی که ضمیمه کردم دریافت کنید.

fateme365

شنبه 17 آبان 1393, 08:16 صبح

سلام
فک میکنم
اگه دادها رو به هر صورت ممکن هم امن درون کوکی ذخیره کنیم باز امنیت برقرار نمیشه و
تنهاه را امنیت در کوکی جلوگیری از سرقت اون باشه

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

eshpilen

شنبه 17 آبان 1393, 10:06 صبح

خوب حالا میایم اطلاعات زیر رو بصورت md5 درمیاریم.
// * the user agent
// * screen size
// * color depth
// * the timezone offset
// * sessionStorage support
// * localStorage support
// * the list of all installed plugins (we're using their names,descriptions, mime types and file name extensions here)

مثل خروجی زیر رو تولید کنه

7d182ededf47c9c4b331edbf9d7e2896

وقتی کاربر لاگین میکنه این هش رو درون سشن قرار میدیم
و دردفعات بعدی میایم دوباره اینکار رو انجام میدیم و اینبار با این سشن مقایسه میکنیم
اگه برابر بود لاگین میومنه
...

مشکل اینه که همهء این اطلاعات بهرحال در سمت کلاینت است و توسط روشهای سمت کلاینت مثل جاوااسکریپت باید اونا بخونیم و بعضیا مثل user agent هم بصورت خودکار به سرور ارسال میشن ولی بازم توسط کلاینت تولید میشن. یعنی تمام این اطلاعات که شما میخونی در سمت کلاینت قابل جعل است و شما هیچ راهی نداری که بتونی مطمئن باشی اون اطلاعات واقعا بصورت طبیعی از یک مرورگر گرفته/ارسال شده و یا توسط هکر جعل شده!
شایدم یه چیزی که شما نمیدونی یا موقتا فراموش کردی اینه که فکر میکنی میتونی الگوریتم برنامت رو پنهان نگه داری و میتونی روی این بعنوان یک فاکتور اصلی امنیت حساب کنی؛ درحالیکه در امنیت اصولی بعکس بطور معمول باید فرض کنی هکر از طرز کار و جزییات برنامهء شما اطلاع کامل داره.
یه هکر که طرز کار سیستم شما رو میدونه و سواد و انگیزهء کافی رو داره طبیعتا میتونه مشخصات سیستم هدف رو هم جعل بکنه. وقتی تونسته کوکی طرف رو بدست بیاره باید فرض کرد که میتونسته اطلاعات دیگر سیستم طرف رو هم بدست بیاره. همونطور که شما میتونی این اطلاعات رو بخونی پس هکر هم میتونه. هکر همونطور که میتونه کوکی کاربر رو در سیستم خودش بسازه میتونه بقیهء اطلاعات سیستم کاربر رو هم بسازه. عملا فرق چندانی بین کپی کردن و جعل کردن تمام این اطلاعات با کپی کردن و جعل کوکی وجود نداره و جعل کردن بقیهء این همه اطلاعات هم کار چندان سختی نیست. اصولا مثلا اگر این اطلاعات رو در سمت کلاینت با js میخونی و هش اون رو به سمت سرور ارسال میکنی، تنها کاری که کافیه هکر بکنه اینه که اون هش رو به سرور بفرسته! (بدون اینکه نیاز باشه هیچ کد js ای رو در سمت خودش اجرا کنه).

bagherok

شنبه 17 آبان 1393, 10:29 صبح

مشکل اینه که همهء این اطلاعات بهرحال در سمت کلاینت است و توسط روشهای سمت کلاینت مثل جاوااسکریپت باید اونا بخونیم و بعضیا مثل user agent هم بصورت خودکار به سرور ارسال میشن ولی بازم توسط کلاینت تولید میشن. یعنی تمام این اطلاعات که شما میخونی در سمت کلاینت قابل جعل است و شما هیچ راهی نداری که بتونی مطمئن باشی اون اطلاعات واقعا بصورت طبیعی از یک مرورگر گرفته یا ارسال شده و یا توسط هکر جعل شده!
شایدم یه چیزی که شما نمیدونی یا موقتا فراموش کردی اینه که فکر میکنی میتونی الگوریتم برنامت رو پنهان نگه داری و میتونی روی این بعنوان یک فاکتور امنیت اصلی حساب کنی؛ درحالیکه در امنیت اصولی بعکس بطور معمول باید فرض کنی هکر از طرز کار و جزییات برنامهء شما اطلاع کامل داره.
یه هکر که طرز کار سیستم شما رو میدونه و سواد و انگیزهء کافی رو داره طبیعتا میتونه مشخصات سیستم هدف رو هم جعل بکنه. وقتی تونسته کوکی طرف رو بدست بیاره باید فرض کرد که میتونسته اطلاعات دیگر سیستم طرف رو هم بدست بیاره. همونطور که شما میتونی این اطلاعات رو بخونی پس هکر هم میتونه.

الان که فک میکنم میبینم این یه تکیه رو فراموش کرده بودم
که بیاد الگوریتم برنامه رو بفهمه
و همه چی رو جعل کنه.

اگه چیزی به ذهنم رسید ادامه میدم
وگرنه که همینجا کات

ممنون از پاسخ هاتون

bagherok

شنبه 17 آبان 1393, 10:38 صبح

هش اون رو به سمت سرور ارسال میکنی، تنها کاری که کافیه هکر بکنه اینه که اون هش رو به سرور بفرسته! (بدون اینکه نیاز باشه هیچ کد js ای رو در سمت خودش اجرا کنه).
ایجکس نیست که ...

منظورم اینه که کدهای جاوا اسکریت اجرا میشه و بعد درون سشن میذارم
این یعنی تبادل هش که بین راه بیاد اسنیف کنه!!!

bagherok

شنبه 17 آبان 1393, 10:42 صبح

باز این نکته رو فراموش کردم که کدهای جاوااسکریپت ما قابل رویت هستند
(ویه چیز دیگه اینکه
js ها سمت کلاینت و php سمت سرور اجرامیشن)

با یه جستجوی ساده به V8Js رسیدم
(الان هیچی ازش نمیدنم باید پیگرش باشم)

eshpilen

شنبه 17 آبان 1393, 11:00 صبح

منظورت شما از دو پست آخرتون برام واضح نبود.

و اما این مقاله رو هم توصیه میکنم مطالعه بفرمایید: security through obscurity / امنیت از طریق تیرگی (http://hamidreza-mz2.tk/?p=461)

bagherok

شنبه 17 آبان 1393, 11:06 صبح

فک میکنم بهتره که دیگه ادامه ندیم
اگه به نتیجه رسیدم همینجا اعلام میکنم.
ممنون.