امنیت

روش امن نگهداری پسورد کاربران

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

ado-breach-5002

 

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

روش اول – پسوردها رو بدون رمزنگاری نگهداریم

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

att-1-plain-5002

در صورتیکه یک شبکه کوچیک دارید و پشتیبانی نفر به نفر ارائه می دید، احتمالا به نظرتون بهتر میاد که پسوردها رو به صورت متن ساده نگهدارید که اگر کسی پسوردش رو فراموش کرد، شما نگاه کنید و بهش بگید. این کار رو نکنید.

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

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

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

روش دوم – رمز کردن پسوردها در دیتابیس

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

att-2-crypted-500

پسوردهای بالا با روش DES رمزگذاری شده. استفاده از DES روش بدیه چونکه از یک کلید ۵۶ بیتی برای رمزگذاری استفاده می کنه. کلیدهای ۵۶ بیتی امکان ۱۰۰ میلیون میلیون پسورد رو ایجاد می کنه که ابزارهای کرک جدید در کمتر از یک روز می تونن بشکوننش.

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

مشکل روش اول همچنان پابرجاست: نه شما و نه هیچکدوم از ادمین ها نباید بتونید پسوردها رو ببینید. در ضمن اگر کسی به سرور شما نفوذ کنه، روش دوم فرق چندانی با روش اول نداره.

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

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

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

روش سوم – هش کردن پسوردها

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

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

در تئوری می شه گفت:

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

از الگوریتم های شناخته شده و پرکاربرد هش کردن می شه به  MD5، SHA-1 و SHA-256 اشاره کرد. از این الگوریتم ها، MD5 پیچیدگی کمتری داره و معنیش اینه که خیلی سریعتر می تونید با استفاده از شانس، دو تا فایل پیدا کنید که نتیجه هش اونها مثل هم باشه.

SHA-1 از نظر محاسباتی مثل MD5 است و کارشناسان معتقدند که به زودی مشخص می شه که ضعف های مشابهی هم داره.

ما روی نمونه پسوردها از الگوریتم SHA-256 استفاده کردیم و هش های نتیجه شده رو در تصویر زیر می تونید ببینید. البته برای جا شدن نتایج، بخشی از اون رو در تصویر نیاوردیم.

att-3-hashed-500

همه هش ها یک طول دارند و بنابراین ما طلاعاتی در مورد طول پسورد اولیه نمی دیم.

همچنین با توجه به اینکه ما می تونیم پیش بینی کنیم که چقدر دیتا برای ذخیره پسورد استفاده می شه، نیازی نیست محدودیتی برای طول پسورد بذاریم. البته برای جلوگیری از فشار روی سرور و ذخیره اطلاعات بیش از حد می شه محدودیت ۱۲۸ یا ۲۵۶ کاراکتری گذاشت دیگه چیزی به عنوان محدودیت ۱۶ کاراکتری برای پسورد وجود نداره.

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

اما روش سوم هم مشکل داره. همونطور که در تصویر می بینید چارلی و داک همچنان هش های ذخیره شده مشابهی دارند که در واقع داریم لو می دیم که پسوردهاشون مشابهه. در واقع کلمه password همیشه نتیجه هش یکسانی برابر با ۵E884898DA28..EF721D1542D8 داره و فرقی وجود نداره. این مشکل به هکرها اجازه می ده که با تولید جدولی از پسوردهای پرکاربر (و یا حتی تولید همه پسوردهای ممکن تا یک طول خاص) و هش کردن اونها، پسورد کاربرها رو با یک جستجو و مقایسه ساده، پیدا کنند.

روش چهارم – هش کردن و استفاده از salt

می تونیم با اضافه کردن یه سری اطلاعات به پسورد، نتایج بهتری از هش به دست بیاریم. این اطلاعات اضافه شده رو salt یا نمک می گن چونکه در واقع داریم به هش های تولید شده یه چاشنی اضافه می کنیم. سالت رو اصطلاحا nonce هم می گن که خلاصه شده number used once یا “عددی که یک بار استفاده می شه” است. به زبان ساده ما یک مجموعه کاراکتر رندوم تولید می کنیم که قبل از هش کردن به پسورد اضافه می شه.

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

حالا دیتابیس ما چیزی شبیه تصویر زیر می شه (بخشی از متغیرها برای جا شدن در تصویر، نشون داده نشده)

att-4-salted

آخرین ستون در این جدول، پسوردهای هش شده است. با ترکیب سالت و پسورد و هش کردن این رشته به دست آمده با الگوریتم SHA-256، اطلاعات ذخیره شده به عنوان پسورد برای چارلی و داک کاملا متفاوته.

مطمئن بشید که سالت های رندومی رو انتخاب می کنید و هرگز از شماره گذاری پیاپی مثل ۰۰۰۰۰۱، ۰۰۰۰۰۲ و مانند آن استفاده نکنید. همچنین از توابع تولید عدد رندوم ضعیفی مثل دستور random در زبان C استفاده نکنید. اگر اینکار رو بکنید سالت های تولید شده می تونه شبیه دیتابیس های دیگه باشه و یا قابل پیش بینی باشه.

با استفاده از توابع رندوم مناسب برای تولید سالت (برای مثال CryptoAPI در ویندوز و  /dev/urandom در سیستم های یونیکس) تضمین می کنید که سالت یکه استفاده می کنید و واقعا عددی است که یک بار استفاده می شه.

تموم شد؟ تقریبا، اما هنوز یکم مونده.

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

hashcrack-500

با مبلغی کمتر از ۲۰ هزار دلار می شه سیستمی رو با ترکیب کارت های گرافیک ایجاد کرد که در هر ثانیه حدود ۱۰۰ میلیارد پسورد هش شده با الگوریتم SHA-256 تولید کنه.

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

روش پنجم – توسعه هش

هش کردن به این معنیه که برای شکستن کد پسوردها، نمی شه رو به عقب رفت اما می شه با روش رو به جلو و امتحان چندین و چندباره لیست پسوردهای احتمالی، به صورت شانسی به پسورد اصلی رسید. یعنی اگر خرابکارها دیتابیس شما رو به دست بیارن و بتونن آفلاین روش کار کنن، چیزی غیر از توانایی CPU جلوی حدس زدن پسوردها رو نمی گیره. اونها می تونن تک تک پسوردهای احتمای از AA..AA تا ZZ..ZZ رو با هر سالت موجود در دیتابیس شما تست بکنن و با مقایسه نتیجه هش، به پسورد کاربر برسن.

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

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

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

با اینحال هرگز خودتون الگوریتمی برای تکرار هش اختراع نکنید. می تونید یکی از این الگوریتم ها رو انتخاب کنید:  PBKDF2،  bcrypt  و یا scrypt

من PBKDF2 رو پیشنهاد می کنم چرا که بر اساس اصول اولیه هش کردن و استانداردهای ملی و بین المللی رو رعایت کرده.

پیشنهاد من استفاده از PBKDF2 با الگوریتم HMAC-SHA-256 و ۱۰ هزار بار تکراره.

hmac-500

 

HMAC-SHA-256 یک روش خاص از پیاده سازی الگوریتم SHA-256 است که اجازه می ده هش با سالت ترکیب بشه:

  • ایجاد یک رشته رندم مثل K و چرخوندن یه سری بیت ها و ایجاد K1
  • هش کردن مجموعه پسورد و سالت با الگوریتم  SHA-256 و تولید H1
  • تغییر بیت های دیگری در K و ایجاد K2
  • محاسبه پسورد هش شده نهایی یا H2 با هش کردن ترکیب H1 و K2

به زبان ساده شما پسورد رو یه بار با یه سالت، هش می کنید و سپس نتیجه رو با نسخه تغییر کرده سالت، دوباره هش می کنید. در PBKDF2 ما یک بار پسورد و سالت رو به الگوریتم HMAC-SHA-256 می دیم و یک دور از ۱۰ هزار دور انجام می شه. سپس خروجی این دور اول رو با پسورد مجددا به الگوریتم HMAC-SHA-256 می دیم و یک دور دیگه اون رو اجرا می کنیم و اینجوری ۹۹۹۹ دور باقیمونده رو انجام میدیم.

pbkdf2-5002

حالا ما باید هش، سالت و تعداد دورها رو در دیتابیس ذخیره کنیم

att-5-pbkdf2-500

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

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

  • از یک تابع قوی تولید عدد رندوم برای تولید یک سالت ۱۶ بایتی یا بیشتر استفاده کنید.
  • پسورد و سالت رو به الگوریتم PBKDF2 بدید.
  • از HMAC-SHA-256 به عنوان هسته هش کردن درون الگوریتم PBKDF2 استفاده کنید.
  • از ۱۰ هزار دور یا بیشتر استفاده کنید (در ابتدای سال ۲۰۱۴).
  • پسورد هش شده ۳۲ بایتی (۲۵۶ بیت) خروجی الگوریتم PBKDF2 خواهد بود.
  • پسورد هش شده، تعداد دورها و سالت رو در دیتابیس ذخیره کنید.
  • برای مقابله با افزایش قدرت پردازنده ها، به صورت دوره ای تعداد دوره های هش رو افزایش بدید.

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

 

منبع

استاندارد
امنیت

بررسی دیتابیس سایت فوربس: کاربران کدام سرویس دهنده ایمیل باهوش‌ترند؟

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

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

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

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

سایت فوربس از PHPass Portable برای هش کردن پسورد استفاده کرده. این فریمورک هر پسورد رو ۸۱۹۳ بار MD5 هش می کنه. این روش برای لاگین کردن کاربرها به اندازه کافی سریعه و برای کرک کردن پیچیده است که کرک کردن رو طولانی و سخت می کنه، مخصوصا وقتی با تعداد زیادی پسورد رو به رو باشیم.

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

البته این قضیه به معنی امن بودن پسوردها نیست. اگر پسورد ضعیفی رو انتخاب بکنیم، این روش هش کردن کمک چندانی نخواهد کرد. برای مثال از یک میلیون پسورد، ۵۰۰ پسورد متعلق به کارمندان فوربس جدا شد و پس از ۱ ساعت حدود یک چهارم پسوردها کرک شد.

forbes-pwds-500

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

ستونی در دیتابیس وجود داره که شامل یک تاریخ می شه. با توجه به اینکه تاریخ ها از سال ۲۰۰۹ شروع شده و تا ۲۰۱۴ و پیش از نفوذ ادامه داشته و با توجه به اینکه تاریخ های اول مربوط به آدرس ایمیل های سایت فوربسه و اولین تاریخ هم مربوط به کاربر ادمین، منطقیه که فرض کنیم این تاریخ، زمان ساخت اکانته.

  • با این فرض می تونیم یک سوال بپرسیم: آیا کیفیت پسوردها از ۲۰۰۹ تا ۲۰۱۴ تغییر کرده؟
  • یا به عبارت دیگه: آیا طی ۵ سال گذشته چیزی در مورد پسورد یاد گرفتیم؟
  • و سوال دیگه می تونه این باشه: آیا تفاوتی بین کیفیت پسوردهای انتخابی کاربران سرویس دهنده های مختلف ایمیل، وجود داره؟
  • یا به عبارت دیگه: کدام سرویس دهنده ایمیل، کاربران آگاه‌تری در مورد پسورد داره؟

بررسی سرویس دهنده های ایمیل، نتیجه مورد انتظاری داشت:

برای بررسی های بعدی ۱۰ هزار ردیف اول و ۱۰ هزار ردیف آخر از هر سرویس دهنده انتخاب شدند، یعنی:

برای لیست پسوردهای پراستفاده نیز از ۱۰۰ پسورد پر استفاده سایت ادوب استفاده کردیم. این لیست پس از افشای دیتابیس این سایت به دست آمده. تنها تفاوت در نمونه هایی بود که پسورد، ترکیبی از اسم ادوب بود که فوربس جایگزینش شد. برای مثال به جای adobe1 و adobeadobe از forbes1 و forbesforbes استفاده شد.

pwlist2-100-500

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

نمودار فشار کاری سی‌پی‌یو در زمان کرک کردن

نمودار فشار کاری سی‌پی‌یو در زمان کرک کردن

قبل از اینکه نتیجه بررسی ها رو بگم، سعی کنید حدس بزنید که پسورد کاربرهای کدوم سرویس دهنده از همه ضعیف تر بوده.

حدس زدید؟

نتیجه بررسی های پسورد کاربرهایی که بین سال ۲۰۰۹ تا ۲۰۱۲ ثبت نام کردند طبق نمودار زیره:

early-500

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

این هم لیست ۶ پسورد ضعیف به ترتیب میزان استفاده. در تصویر می بینید که همچنان password و ۱۲۳۴۵۶ در صدر جدول بدترین پسوردها به چشم می خورند.

top6-early-500

و نتیجه بررسی های مشابه برای کاربرهایی که در سال های ۲۰۱۳ و ۲۰۱۴ ثبت نام کرده اند به این شکله:

recent-500

در این لیست امن‌ترین کاربرها، کاربران ایمیل یاهو اند. حدس نمی زدید، نه؟

و بدترین پسوردها رو هم می تونید در تصویر زیر ببینید. به نظر می رسه کاربرهای AOL و HOTMAIL به جای ۱۲۳۴۵۶ از ۱۲۳۴۵۶۷۸۹ و ۹۸۷۶۵۴۳۲۱ استفاده کرده اند که همچنان پسورد ضعیفی است.

top6-recent-500

خبر خوب اینکه کاربرانی که جدیدتر ثبت نام کرده اند، پسوردهای بهتری انتخاب کرده اند یا بهتره بگیم پسوردهای بد کمتری استفاده کرده اند.

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

و بازهم بیشترین تغییر مثبت رو کاربران یاهو داشتند.

منبع

استاندارد
امنیت

ضعف امنیتی پرینترهای اچ‌پی

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

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

این ضعف امنیتی که با کد CVE-2013-4807 شماره گذاری شده، توسط Michał Sajdak کشف شده. این محقق توضیح داده که برخی URL های مخفی در Firmware پرینترهای اچ‌پی به هکر اجازه می ده پسوردهای وایفای و ادمین رو به صورت متن ساده ببینه.

M1217nfw (C) HP

M1217nfw (C) HP

برای مثال اگر به این آدرس مراجعه کنید:

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

در تصویر زیر می بینید که هکر تونسته پسورد ادمین رو ببینه. البته در این تصویر ۰x746573746f7765 معادل مبنای ۱۶ پسورده که اینه testowe.

hp-hex-password

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

همچنین اگر وایفای پرینتر فعال باشه، از آدرس زیر به پسورد دسترسی خواهیم داشت:

در تصویر زیر می بینید که WPS PIN به وضوح نوشته شده.

hp-wps-pin

خبر خوب اینه که Hewlett-Packard نسخه جدید firmware های مدل های فوق رو منتشر کرده که از این لینک می تونید دانلود کنید. کافیه در صفحه باز شده، گزینه Drivers & Software را انتخاب کنید. سپس با جستجوی مدل پرینتر خودتون و انتخاب سیستم عاملتون، نسخه جدید رو دانلود کنید.

خبر بد می تونه این باشه که زمان زیادی خواهد برد تا استفاده کننده های این مدل ها از وجود همچین مشکلی خبر دار شده و یا Firmware رو آپدیت کنند.

منبع

استاندارد