دفترچه

من كدتون رو ندیدم چون روی پی سی نت ندارم فعلن ، فقط خواستم بدونم برای رمز نگاری كلمه عبور فقط به یك md5 خالی بسنده كرده اید یا salt هم بهش اضافه كردید ؟

sonixax نوشته: من كدتون رو ندیدم چون روی پی سی نت ندارم فعلن ، فقط خواستم بدونم برای رمز نگاری كلمه عبور فقط به یك md5 خالی بسنده كرده اید یا salt هم بهش اضافه كردید ؟

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

بنده در تابع هش برنامم از SHA256 استفاده کردم؛ چون MD5 مدتهاست سوراخ شده؛ همچنین SHA1 هم دیگه منسوخه برای این کاربرد.
البته استفاده از اینا برای کاربرد هش اگر با بقیهء متدها ترکیب بشن اونقدرها هم ضعیف نیست، ولی بهرصورت اکیداً بهتره اجتناب بشه.

کلا 4 مسئلهء اساسی در هش پسورد هست که من با انبوهی تحقیقات به این خلاصه رسیدم:

- سالت ثابت (که معمولا در جایی غیر از دیتابیس ذخیره میشه)
این سالت یک رشتهء رندوم است که برای کل پسوردها یکسانه و استفاده میشه.

- سالت رندوم به ازای هر پسورد
این سالت در دیتابیس همراه هش پسورد ذخیره میشه.

- متد Key stretching
این متد یعنی تکرار عملیات هش پسورد همراه با سالت و اینها، به تعداد بالا (حداقل چند هزار بار).

- آخریش هم استفاده از الگوریتم های مخصوص هش مثل bcrypt و scrypt
این الگوریتم ها مخصوص هش طراحی شدن و مثلا Key stretching رو سرخود دارن. طوری طراحی شدن که حمله های کرک رو تاحداکثر ممکن سخت کنن.
scrypt جدیدتر و قویتره، ولی زیاد استفاده نمیشه؛ حتی bcrypt هم خیلی زیاد جا نیافتاده (ولی ظاهرا آمار قابل توجه داره).
scrypt حمله های سخت افزاری جدید رو هم بحساب آورده و هزینهء اونا رو به شدت زیاد کرده.

حالا من اومدم و الگوریتم هش خودم رو که این سه متد اول درش رعایت شده باشه خودم با SHA256 طراحی کردم، ولی اصولی تر و قوی ترش اینه که از bcrypt یا scrypt استفاده بشه. البته توجه کنید که مثلا سالت ثابت رو خودتون باید به ورودی bcrypt اضافه کنید.

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

راستی در تولید سالتها باید دقت بشه که:

1- از توابع رندوم امنیتی استفاده بشه.
2- تعداد حالتهای سالت بقدر کافی زیاد باشه (من ترجیح دادم ریسک نکنم و از 2 به توان 128 حالت که استاندارد رمزنگاریه استفاده کردم).

folaani نوشته: بنده در تابع هش برنامم از SHA256 استفاده کردم؛ چون MD5 مدتهاست سوراخ شده؛ همچنین SHA1 هم دیگه منسوخه برای این کاربرد.

نه Md5 سوراخ نیست !
یک ضرب المثل قدیمی بین برنامه نویسان c++ هست که میگه : "هرگز نمیتونی از یک همبرگر گاو زنده درست کنی" .
تنها راه برگردان هش چه Md5 چه غیره استفاده از بروتفورس در کنار یک بانک اطلاعاتی هستش . بعضی ها مثل اینها یک دیتابیس خیلی بزرگ از هر هشی رو دارند : CrackStation - Online Password Hash Cracking - MD5, SHA1, Linux, Rainbow Tables, etc.
تهیه کردن این دیتابیس ها هم کار چندان سختی نیست - با کمی جستجو پیدا میکنید .

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

چند راه خیلی خوب برای محافظت از سالت وجود داره :

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

2 - در برخی جاها که حفاظت از اطلاعات خیلی مهمه یک سرور دیگه با IP جداگانه درنظر گرفته میشه و سالتها روی اون ذخیره میشند . دسترسی تمام IP ها به جز IP سروری که اسکریپت روش اجرا میشه به سرور ریموت بسته میشه . طبیعی هست که این روش هزینه اش هم بیشتره . حتا ممکنه که بخشی از سالت روی یک ریموت سرور و بخش دیگرش روی یک ریموت سرور دیگه باشه یا اصلن بیش از یک سالت روی بیش از یک ریموت سرور باشه .

3 - من دیده ام که برخی از برنامه نویسان حتا خود هش رو هم روی یک سرور دیگه نگهداری میکنند .
4- تا جای ممکن بهتره که دسترسی فیزیکی به هیچ کدام از سرورها وجود نداشته باشه و حتا بهتره سرورها در یک پایگاه واحد نباشند - که البته این دیگه از نکات برنامه نویسی نیست

دست آخر بهتره از یکی روشهای یک یا 2 در اسکریپتتون بهره ببرید چون هر هشی با صرف زمان کافی و سخت افزار مناسب قابل هک شدن هست .
حتا روشهای 1 و 2 هم تضمین 100% ای برای حفاظت نمیدند و باید همواره روشها رو عوض کرد و پیچیده ترشون کرد - این یک جنگه و کسی که از یک روش مشخص و همیشگی استفاده میکنه شکست میخوره .

نسخهء 2 آماده شد.

در این نسخه:

- چندتا باگ رفع شد.
بعضی باگها یه مقدار امنیتی هم بودن (نه در حد وخیم).

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

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

- امکان بخاطرسپاری لاگین (گزینهء remember me) در این نسخه بصورت فوق العاده قابل کانفیگ و منعطفی در اومده. الان میتونیم تعیین کنیم که کاربران بتونن چند و چگونه گزینه های بخاطرسپاری در فرم لاگین داشته باشن. مثلا میتونیم بخاطرسپاری برای 5 دقیقه، یک ساعت، یک هفته، یک ماه، یک سال و غیره رو بصورت یک منو بجای چک باکس remember me که در نسخه های قبلی وجود داشت داشته باشیم.
این منو میتونه یک یا هر تعدادی گزینه داشته باشه.
ضمنا گزینه های بخاطرسپاری کاربران عادی و ادمین از هم کاملا جداست و میتونن هرکدام آپشن های کاملا متفاوتی داشته باشن. به این میگن آخر انعطاف و قابلیت پیکربندی!
این زمانهای بخاطرسپاری در سمت سرور هم چک میشن و بنابراین قابل دور زدن توسط کاربران در سمت کلاینت نیستن. بطور مثال شما میتونید کاربران رو مجبور کنید که بخاطرسپاری لاگین اونها بیش از 8 ساعت نباشه.
برای اطلاع بیشتر، متغییرهای کانفیگ autologin_ages و admin_autologin_ages در فایل config_identify.php رو نگاه کنید.

- امکان دیگر اضافه شده اینه که اگر یادتون باشه موقعی که ثبت نام صورت میگرفت، کاربر بصورت خودکار تا زمان باز بودن مرورگر لاگین میشد. البته این لاگین خودکار بعد از ثبت نام رو میشه با false کردن متغییر login_upon_register در فایل config_register.php غیرفعال کرد.
الان یک متغییر دیگر هم به این جریان اضافه کردم بنام login_upon_register_age که میتونید باهاش طول عمر این لاگین خودکار رو تعیین کنید. مثلا تعیین کنید که کاربر فقط برای یک ساعت لاگین بمونه، یا هر زمان دیگری که میخواید، مثلا تا همون باز بودن مرورگر.

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

- طول عمر لاگین های خودکار که تا باز بودن مرورگر برقرار هستن الان بوسیلهء متغییر max_session_autologin_age در فایل config_identify.php قابل محدود کردن است. بنده مقدار پیشفرض رو روی 12 ساعت تنظیم کردم.
این گزینه هم از نظر امنیتی اهمیت داشت، چون کوکی هایی که طول عمرشون به اندازهء باز بودن مرورگر تعیین میشه عملا محدودیت زمانی ندارن و این به دلایلی که در گزینهء قبلی توضیح دادم میتونه خطرناک باشه.
الان میتونید برای عمر اینطور لاگین ها یک حداکثر تعیین کنید. اگر مرورگر کاربر زودتر از این زمان بسته شد، کوکی پاک شده و لاگین خودکار از بین میره، و اگر مرورگر همینطور باز بمونه بازهم طول عمر لاگین خودکار نمیتونه از زمان تعیین شده بیشتر بشه، چون در سمت سرور چک میشه.

خب این از ویژگیهای این نسخه!
فقط این هست که این نسخه رو خیلی تست نکردم چون نه دیگه وقت داشتم نه حس و حال و اولویتش رو.
use at your own risk
ولی خب نه اینکه هیچ تستی نکرده باشم؛ تاجایی که بنظرم صرف میکرد (واسه خودم) تست و باگیابی و باگزدایی کردم.
اگر باگی چیزی دیدید گزارش کنید خب!

sonixax نوشته: چند راه خیلی خوب برای محافظت از سالت وجود داره :

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

2 - در برخی جاها که حفاظت از اطلاعات خیلی مهمه یک سرور دیگه با IP جداگانه درنظر گرفته میشه و سالتها روی اون ذخیره میشند . دسترسی تمام IP ها به جز IP سروری که اسکریپت روش اجرا میشه به سرور ریموت بسته میشه . طبیعی هست که این روش هزینه اش هم بیشتره . حتا ممکنه که بخشی از سالت روی یک ریموت سرور و بخش دیگرش روی یک ریموت سرور دیگه باشه یا اصلن بیش از یک سالت روی بیش از یک ریموت سرور باشه .

هه هه :e057:
دوست عزیز نیازی نیست این همه سالت رو جای دیگه ذخیره کنید.
این فرمول رو ببین:
pepper همون سالت ثابت است که در هش تمام پسوردها دخالت میکنه. همونطور که میبینی هر پسورد سالت رندوم خودش رو هم داره.
کافیه فقط یک رشته، یعنی سالت ثابت (pepper)، در جای امنی غیر از دیتابیس ذخیره بشه. در این صورت هکر نمیتونه هیچ کاری با هش ها بکنه، اقدام به Brute-force بکنه، مگر اینکه سالت ثابت رو داشته باشه. دیگه چه نیازی هست که مثلا صدهزار اکانت داریم صدهزارتا سالت هم روی سرور دیگری ذخیره کنیم؟ اگر هکر به سرور دیگر نتونه دسترسی داشته باشه نتونه سالت ثابت رو بدست بیاره نمیتونه هیچ غلطی بکنه، و اگر بتونه و دسترسی بدست بیاره که دیگه فرقی نمیکنه شما اونجا چی رو ذخیره کرده باشی تمام سالتها باشن یا فقط یک سالت ثابت.

نقل قول:3 - من دیده ام که برخی از برنامه نویسان حتا خود هش رو هم روی یک سرور دیگه نگهداری میکنند.
4- تا جای ممکن بهتره که دسترسی فیزیکی به هیچ کدام از سرورها وجود نداشته باشه و حتا بهتره سرورها در یک پایگاه واحد نباشند - که البته این دیگه از نکات برنامه نویسی نیست

دست آخر بهتره از یکی روشهای یک یا 2 در اسکریپتتون بهره ببرید چون هر هشی با صرف زمان کافی و سخت افزار مناسب قابل هک شدن هست .
حتا روشهای 1 و 2 هم تضمین 100% ای برای حفاظت نمیدند و باید همواره روشها رو عوض کرد و پیچیده ترشون کرد - این یک جنگه و کسی که از یک روش مشخص و همیشگی استفاده میکنه شکست میخوره .

معمولا این روشها در عمل صرف نمیکنه و معقول نیست. گذشته از اینکه اصولا اینکه فرض کنید با اضافه کردن یک سرور دیگر و نیاز به تبادل اطلاعات بین این دو سرور، امنیت لزوما خیلی بالا میره، لزوما فرض درستی نیست. چطوری محاسبه چطوری اثباتش میکنید؟ هر سرور خودش یک نقطهء شکست اضافه میکنه چون میتونه نقاط ضعف و حفره های امنیتی و امکان دسترسی افراد دیگری رو داشته باشه. ارتباط بین دو سرور و تبادل شدن اطلاعات حساس از کانال ارتباطی هم خودش نقطهء شکست دیگری رو ایجاد میکنه و امکان دسترسی غیرمجاز این وسط، که البته میشه با استفاده از رمزنگاری اطلاعات رد و بدل شده تاحد زیادی این ضعف رو برطرف کرد، ولی بهرحال بحث ضعف بیشتر در برابر حمله های DOS هم هست، چون صرف بستن راه ارتباط برنامه و نرسیدن یا خراب کردن اطلاعاتی که نیاز داره میتونه باعث اختلال در سرویس دهی و در نتیجه DOS بشه.
از طرف دیگر بهرحال وابسته شدن کارکرد برنامه به چند سرور و ارتباط بین اونها و ارتباطات شبکه ای یا اینترنتی، از نظر سرعت و پرفورمنس و نیز پایداری و Reliability، خوب نیست، چون اگر قبلا 2% احتمال خرابی چیزی و از کار افتادن سرور و سایت بوده حالا احتمال خرابی بخشهای مربوط به سرور دیگر و تمام کانال های ارتباطی و سیستمهای درگیر هم بهش اضافه میشه و این درصد بالاتر میره (جمع احتمال خرابی تمام سرورها و اتصالات شبکه و سیستمهای درگیر).
و این همه هزینه بخاطر چی؟ بخاطر اینکه امنیت هش ها رو یک مقدار بالا ببریم که چندان هم زیاد نیست و نمیشه دقیق محاسبه و ثابت کرد و مطمئن بود.
در برنامه ها معمولا اونقدری نقاط ضعف و مجهولات وجود دارن که این همه هزینه و محکم کاری در فقط یک بخش، معقول نیست. حداقل نه در برنامه های معمولی در مقیاس معمولی.
منکه میگم حتی سالت ثابت رو هم روی همون سرور ذخیره کنید، ولی خب جدای از هش ها در دیتابیس باشه و ترجیحا در مکانی که تاحدی حفاظت شده باشه. من در برنامهء خودم سالت ثابت رو صرفا در فایلهای کد خود برنامه قرار دادم، ولی متخصصان توصیه میکنن که جای حفاظت شده تری باشه یک سیستم و کنترل دسترسی درست حسابی تری داشته باشه، ولی خب چنین چیزی ساده نیست و بنظر من برای برنامه های معمولی همون حد معقوله و کفایت میکنه چون بیشترش دیگه دردسر و هزینه های جانبی زیاد داره صرف نمیکنه.

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

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

ولی خب یه عده امثال شما هستن دیگه اینقدر ادعاشون میشه اینقدر سطحی هستن اینقدر غرور دارن که اینطور عمل نمیکنن و خودسر و خودمحور هستن.

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

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

از کم آوردنت! گریه زاریت! بچه بازیت و اینکه میبینیم به این حال و روز انداختمت لذت میبرم
در ضمن هک کردن MD5 بنا بر فتوای آخوند چینی فراموش نشود

sonixax نوشته: از کم آوردنت! گریه زاریت! بچه بازیت و اینکه میبینیم به این حال و روز انداختمت لذت میبرم
در ضمن هک کردن MD5 بنا بر فتوای آخوند چینی فراموش نشود

جالبه چون حرفی رو زدی که دقیقا برعکس من باید بهت بزنم.
چون واضحه این وسط کسی که به یاوه گویی و ابتذال محض آشکار رسیده کیه!
من تاحالا مجبور نشدم حتی یک جمله یاوه و چرند و حرف غیرمنطقی بزنم. این شما بودی که زیر دفاع از غرور مسخرهء خودت زاییدی. ناخوشایندترین و بدترین شکل مثل خر توی گل موندن هم همینه خب جانم :e405:

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

ولی تو مثل اینکه پوستت حسابی کلفت مونده تاحالا
هه هه!
حالا فکر میکنی مثلا به چی رسیدی؟!

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

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

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

بقول طرف میگه آنچه مرا نکشد مرا قویتر خواهد ساخت!

باز هم که شروع کردی زیاده نویسی! زیر شعله رو میخوای کم کنم کمتر جوش بزنی ؟
کسی که میره تاپیک زیر خاکی میاره بالا اون هم خطاب به کس دیگه ای که در بحثهای دیگه باهاش شرکت داره مشخصن درجه حرارتش از 100 هم زده بالاتر:)))
پس یک لیوان آب تگری بنوشید جانم!

sonixax نوشته: باز هم که شروع کردی زیاده نویسی! زیر شعله رو میخوای کم کنم کمتر جوش بزنی ؟
کسی که میره تاپیک زیر خاکی میاره بالا اون هم خطاب به کس دیگه ای که در بحثهای دیگه باهاش شرکت داره مشخصن درجه حرارتش از 100 هم زده بالاتر:)))
پس یک لیوان آب تگری بنوشید جانم!

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