Mehrbod نوشته: اگر که mysql روی سرور یکی از encoding‌هایِ زیر را ببیوسد[SUP][2][/SUP]: GBK or BIG-5

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

نقل قول:با همه‌یِ اینها من فرزامگرایی[SUP][3][/SUP] بیش از اندازه‌ای در کدت میبینم که به نگرم برای همان خودنمایی بوده باشد ((:

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

نقل قول:نکته‌یِ crypt_random ٸه دستکاری شده چیه؟ درگاشت[SUP][4][/SUP] را از کجا گرفته‌ای؟
...
ولی همچنان درگاشت نابِ ناب نیست و هنوز اسپاش[SUP][5][/SUP] به اندازه‌یِ بسنده random نیست.
من پیشتر یک خوارزم[SUP][6][/SUP] رازنگاری نوشته بودم برای rsa که درگاشت را از cpu میگرفت, نمیدانم روی php چه اندازه دسترسی به hardware داریم, ولی
این ورتنده‌ها[SUP][7][/SUP] (time, remote_addr, serialaized post, etc) همگی هنوز پیشبینی‌پذیر میباشند و به اندازه‌ای که باید و شاید درگاشت[SUP][4][/SUP] را بزرگ نمیکنند (:

خب موضوع اینه که این سیستم جمع آوری و استفاده از آنتروپی تولید شده توسط کلاینت فقط یک آنتروپی افزوده و محکم کاریه و اساس سیستم نیست. دیگه من خیلی سیستم رو محکم کاری و شاید حتی Overkill کردم؛ چون در اصل از توابع دیگری در درون تابع رندوم استفاده شده که خودشون توابع/منابع رندوم از نوع امنیتی/رمزنگاری بحساب میان (openssl_random_pseudo_bytes، /dev/urandom، mcrypt_create_iv) و امروزه بعیده حداقل یکی از اینها روی سیستمی در دسترس تابع نباشه. آنتروپی این منابع خودش کافیه و برنامه های رمزنگاری دارن از اینا استفاده میکنن، ولی خب در امنیت در هیچ کجا اطمینان 100% هم نیست و اینها هم میتونن مواردی از کم کفایتی و حمله و شرایط نامساعد دچار بشن (حداقل از نظر تئوریک).
این آنتروپی که من اضافه کردم در بدترین حالت میتونه نزدیک به صفر باشه، و هیچوقت آنتروپی سیستم کمتر از آنتروپی اون توابع امنیتی نمیشه. آنتروپی ای که من گذاشتم (البته به کمک اون دوست خارجی - ایدش از ایشون بوده)، باعث افزایش اطمینان در ترکیب با اون توابع میشه، و اگر در موارد نادری هیچکدام از اون توابع امنیتی در دسترس نبودن، باز یک منبع آنتروپی بسیار با ارزشی رو تامین میکنه که همون هم برای کاربردهای عادی شاید خیلی بیش از حد مورد نیاز هم باشه.

البته اینم بگم که یک دلیل افزوده شدن این سیستم آنتروپی، ضعف اولیهء تابع رندوم ایشون بود که بنده دیدم و با خودش هم مطرح کردم و بحث افزودن منابع آنتروپی از اون موقع افتاد وسط و شاید دست آخر دیگه اصلا نیازی نبود، چون چند تابع دیگر برای گرفتن آنتروپی از منابع رسمی سیستم رو به تابع ایشون اضافه کردم که دیگه 99% روی سیستمها حداقل یکی از اینا پیدا میشه.
تابع اصلاح شدهء بنده الان از تابع اون موقع ایشون خیلی بهتر هم هست. ولی نمیدونم این تغییرات مفید رو ایشون در تابع خودش هم اعمال کرد یا نه.
البته اون openssl_random_pseudo_bytes رو تاجاییکه یادمه به نسخهء بعدی تابع در SVN اضافه کرد. منتها اضافه کردن mcrypt_create_iv هم مهم بود، چون از openssl_random_pseudo_bytes همونطور که در کد و کامنت هاش میبینید در روی ویندوز بخاطر کندی غیرعادیش استفاده نمیشه، و روی ویندوز /dev/urandom رو هم که نداریم!