اگر از برنامه Passwords اپل برای دریافت هشدار رمزهای لو رفته استفاده می‌کنید، به‌زودی دستگاه شما خودش عملیات پاک‌سازی را انجام می‌دهد. طبق اعلام اپل در بتای توسعه‌دهندگان که در ۸ ژوئن ۲۰۲۶ منتشر شد، سیستم‌عامل‌های iOS 27، iPadOS 27 و macOS 27 به Apple Intelligence اجازه می‌دهند تا در وب‌سایت‌ها پیمایش کرده و رمزهای عبور ضعیف یا لو رفته را به‌طور خودکار جایگزین کنند.
این تغییر، هوش مصنوعی را از یک ناظر غیرفعال به یک عامل فعال تبدیل می‌کند که بر هویت دیجیتال شما تسلط دارد. برای اکثر کاربران، فرآیند امنیتی فعلی ناکارآمد است؛ مردم اغلب هشدارهای نشت داده را نادیده می‌گیرند چون پیمایش در تنظیمات حساب‌ها خسته‌کننده است. وب‌سایت‌ها ممکن است تنظیمات را پنهان کنند، ممکن است حساب از کاربر مرحله تأیید دیگری بخواهد، یا کاربر صرفاً ۴۰ هشدار دیگر داشته باشد که پشت هشدار اول منتظر هستند. هشداری که هرگز به اقدام تبدیل نشود، عملاً هیچ کنترلی ایجاد نمی‌کند.
اپل با خودکارسازی ورود و جایگزینی رمزها و نمایش پیشرفت آن در قالب یک Live Activity، قصد دارد شکاف بین شناسایی نشت و اقدام اصلاحی را پر کند. اما مرز باریکی بین شناسایی و داشتن اختیار وجود دارد. شناسایی یعنی مشاهده، اما تغییر رمز یعنی داشتن اختیار. سؤال اصلی این نیست که آیا هوش مصنوعی می‌تواند دکمه «تغییر رمز» را پیدا کند، بلکه این است که ما چه مقدار اختیار به آن می‌دهیم یک بار که آن دکمه را یافت.
سازوکار چرخش خودکار رمزها
به نقل از گزارش kylereddoch.me، این قابلیت جدید از طریق ادغام برنامه Passwords با Safari عمل می‌کند. برنامه Passwords اپل در حال حاضر رمزهای تکراری، ضعیف و لو رفته را شناسایی می‌کند. قابلیت نظارت بر رمزها (Password Monitoring) از تکنیک‌های حفظ حریم خصوصی استفاده می‌کند تا رمزهای ذخیره‌شده را با فهرستی از رمزهای لو رفته مقایسه کند، بدون اینکه رمزهای کاربر را برای اپل فاش کند.
پیش از این، فرآیند با هدایت کاربر به وب‌سایت برای رفع مشکل به پایان می‌رسید. این دقیقاً جایی است که توصیه‌های امنیتی معمولاً می‌میرند. تحقیقات نشان می‌دهد کاربران به‌طور قابل‌اعتمادی رمزهای لو رفته را تغییر نمی‌دهند و وقتی هم این کار را می‌کنند، اغلب رمز جدید را در جای دیگری تکرار می‌کنند یا چیزی بسیار شبیه به رمز قبلی انتخاب می‌کنند. دستورالعمل‌های فعلی NIST در زمینه هویت دیجیتال پیشنهاد می‌کند که سرویس‌ها در صورت مشاهده نشت بدیهی، کاربر را مجبور به تغییر رمز کنند، اجازه استفاده از مدیریت‌کننده‌های رمز را بدهند و رمزهای لو رفته شناخته‌شده را مسدود کنند. قابلیت اپل این قطعات را به هم متصل می‌کند.
اگر برنامه Passwords یک رمز لو رفته را شناسایی کند، یک جایگزین قوی و منحصربه‌فرد بسازد، وب‌سایت را به‌روزرسانی کند و رمز جدید را به‌درستی ذخیره کند، می‌تواند زمان مفید بودن یک رمز لو رفته برای مهاجم را به‌شدت کاهش دهد. این یعنی کاربران عادی بدون کلنجار رفتن با تنظیمات هر وب‌سایت به‌صورت جداگانه، از مزیت رمزهای منحصربه‌فرد بهره می‌برند.
این عامل یک گردش کار پیچیده را اجرا می‌کند: سایت را باز می‌کند، وارد می‌شود، تنظیمات حساب را می‌یابد، رمز فعلی را وارد می‌کند، رمز جدیدی می‌سازد و آن را در گاوصندوق ذخیره می‌کند. این یک تولید متن ساده نیست. این یک اقدام با اثر بالا است که نیازمند مدیریت موارد زیر توسط عامل است:
- تغییر مسیرها (Redirects) و پنجره‌های پاپ‌آپ
- قوانین پیچیدگی غیرمعمول رمز عبور
- چالش‌های احراز هویت چندعاملی (MFA)
- ایمیل‌های تأیید و نشست‌های (Sessions) منقضی‌شده
- مدیریت چندین حساب در یک دامنه واحد
- صفحاتی که از زمان آموزش یا تست عامل تغییر کرده‌اند
تهدید تزریق پرامپت
خطر اصلی در این واقعیت نهفته است که این عامل‌ها در وب آزاد عمل می‌کنند؛ محیطی با ورودی‌های غیرقابل اعتماد. عامل‌های مرورگر باید محتوای صفحه را بخوانند تا تصمیم بگیرند چه کنند. اما وب‌سایت‌ها رابطه‌های خنثی نیستند؛ آن‌ها حاوی اسکریپت‌ها، تبلیغات، فریم‌های جاسازی‌شده و محتواهای تولیدشده توسط کاربر هستند که توسط شخص ثالث کنترل می‌شوند.
بر اساس گزارش‌های Anthropic، هیچ عامل مرورگری به‌طور کامل در برابر تزریق پرامپت (Prompt Injection) — شبیه وقتی که کسی با یک یادداشت مخفی در لایه‌ی زیرین یک نامه، نویسنده را مجبور به تغییر پیام می‌کند — مصون نیست. هر صفحه‌ای که عامل می‌بیند، یک بردار حمله است. مرکز امنیت سایبری ملی بریتانیا بر مشکلی عمیق‌تر تأکید می‌کند: مدل‌های زبانی بزرگ فعلی نمی‌توانند مرز امنیتی قابل‌اعتمادی بین «دستورات» و «داده‌ها» در داخل یک پرامپت ایجاد کنند.
این موضوع حیاتی است زیرا عامل در حال خواندن وب‌سایت است در حالی که اختیار تغییر رمز حساب را دارد. یک وب‌سایت مخرب، یک تبلیغ هک‌شده، یک ویجت پشتیبانی تزریق‌شده یا یک صفحه حساب تحت کنترل مهاجم می‌تواند دستورات پنهانی داشته باشد تا هوش مصنوعی را مجبور کند:
- رمزهای عبور را به‌جای فرم مورد انتظار، به سرور تحت کنترل مهاجم بفرستد
- MFA را به بهانه «الزام برای به‌روزرسانی» غیرفعال کند
- یک ایمیل بازیابی متعلق به مهاجم را اضافه کند
- ابتدا یک تنظیم امنیتی دیگر را تغییر دهد
- حتی اگر رمز ذخیره نشده باشد، گزارش موفقیت‌آمیز بودن تغییر را ارسال کند
اگرچه اپل ممکن است رمزها را از مدل جدا کند یا از کنترل‌های قطعی استفاده کند، اما عبارت «هوش مصنوعی روی دستگاه اجرا می‌شود» پاسخ امنیتی کاملی نیست. پردازش روی دستگاه حریم خصوصی را بهبود می‌بخشد، اما محتوای خصمانه وب را قابل اعتماد نمی‌کند.
چراغ‌های قرمز معماری
متخصصان امنیت می‌پرسند آیا مدل هوش مصنوعی هرگز رمزهای عبور را به‌صورت متن ساده می‌بیند؟ امن‌ترین معماری آن است که مدل از اسرار واقعی جدا باشد. مدل فقط باید تشخیص دهد که صفحه شامل فیلد «رمز فعلی» و «رمز جدید» است، اما نیازی ندارد خودِ رمز را بداند.
یک سرویس مدیریت اعتبار مجزا و به‌شدت کنترل‌شده باید عملیات پر کردن را تنها پس از تأیید منشأ وب‌سایت، حساب مورد نظر و اقدام تأییدشده انجام دهد. عامل باید بتواند بگوید «فیلد تأییدشده‌ی رمز فعلی را برای این حساب پر کن»، اما نباید بتواند رمز را بخواند، کپی کند، خلاصه کند، تغییر دهد یا ارسال کند. این جداسازی حیاتی است زیرا هر چیزی که در بافت (Context) مدل قرار گیرد، بخشی از یک سطح حمله بزرگ‌تر شامل لاگ‌ها، حافظه، تله‌متری و رفتارهای غیرمنتظره می‌شود.
همچنین خطر «شکست جزئی» وجود دارد. اگر عامل رمز را در سایت تغییر دهد اما در ذخیره آن در برنامه Passwords شکست بخورد، کاربر عملاً از حساب خود بیرون می‌افتد. این اتفاق می‌تواند به دلایل زیر رخ دهد:
- سایت تغییر را پذیرفت اما صفحه تأیید غیرمنتظره‌ای را باز کرد
- شبکه پس از ثبت رمز جدید توسط سایت قطع شد
- رمز تحت یک حساب یا زیردامنه اشتباه ذخیره شد
- وب‌سایت برخی نویسه‌ها را به‌طور خاموش حذف یا رد کرد
- حساب از نام کاربری جداگانه‌ای استفاده می‌کند که عامل آن را به‌اشتباه تطبیق داده است
- عامل یک موفقیت را شکست تفسیر کرد و دوباره تلاش نمود
- کاربر دارای اعتبارنامه‌های مشترک یا مدیریت‌کننده رمز دیگری است که اکنون حاوی داده‌های قدیمی است
اگرچه Safari از استاندارد /.well-known/change-password برای یافتن صفحه تغییر رمز پشتیبانی می‌کند، اما این یک API استاندارد و اتمیک برای چرخش رمز نیست تا ثابت کند گردش کار به‌درستی تکمیل شده است. پیش از اعتماد به این سیستم، باید بدانیم اپل چگونه موفقیت را تأیید می‌کند، از اعتبارنامه پیش از ارسال محافظت می‌کند و در صورت اختلاف بین سایت و گاوصندوق، به کاربر کمک می‌کند.
گسترش شعاع تخریب
خودکارسازی، هم مزایا و هم ریسک‌ها را مقیاس می‌کند. در حالی که انسان یک رمز را در هر بار تغییر می‌دهد، یک عامل می‌تواند ده‌ها رمز را در یک صف بچرخاند. اگر دستگاهی هک شود یا مهاجم به یک نشست باز دسترسی پیدا کند، این قابلیت مسیری سریع برای نابود کردن کل ردپای دیجیتال کاربر فراهم می‌کند. راهنمای مشترک Five Eyes درباره هوش مصنوعی عامل‌محور هشدار می‌دهد که امتیازات یک عامل مستقیماً ریسک ایجاد شده را تعیین می‌کند و توصیه می‌کند برای اقدامات با اثر بالا، اصل «حداقل دسترسی»، نظارت شدید و تأیید انسانی الزامی باشد.
عاملی که می‌تواند رمزهای زیادی را تغییر دهد، سه قدرت خطرناک دارد:
۱. می‌تواند به‌عنوان کاربر احراز هویت کند.
۲. به سری (Secret) که حساب را کنترل می‌کند دسترسی دارد.
۳. می‌تواند آن سری را جایگزین کند تا دسترسی خود کاربر را باطل کند.
این اعتماد زیادی است که به یک سیستم خودکار سپرده می‌شود. علاوه بر این، چرخش رمز اغلب یک راهکار سطحی است. اگر مهاجم قبلاً یک نشست دائمی ایجاد کرده یا ایمیل بازیابی را کنترل می‌کند، تغییر رمز فقط یک «تیک سبز آرام‌بخش» ایجاد می‌کند بدون اینکه امنیت را واقعاً برگرداند.
اتحاد FIDO اشاره می‌کند که حرکت به سمت کلیدهای عبور (Passkeys) — که رمزهای مشترک را با جفت‌کلیدهای رمزنگاری جایگزین می‌کنند — بسیار ارزشمندتر از چرخش مکرر رمزها است. عاملی که رمز را تغییر می‌دهد اما یک بازگشت SMS ضعیف، یک ایمیل بازیابی ضعیف یا یک نشست تحت کنترل مهاجم را دست‌نخورده باقی می‌گذارد، حساب را ایمن نمی‌کند. همان‌طور که در تحلیل‌های قبلی اشاره کردیم، ضعیف‌ترین مسیر احراز هویت یا بازیابی باقی‌مانده است که نتیجه نهایی را تعیین می‌کند.
نیاز به شفافیت
متخصصان استدلال می‌کنند که اپل پیش از عرضه رسمی در پاییز، باید مرزهای امنیتی خود را مستند کند. نمایش پیشرفت در Live Activity شروع خوبی است، اما با پاسخگویی یکی نیست. کاربران به یک ردپای حسابرسی بادوام نیاز دارند که نشان دهد:
- کدام حساب و به چه دلیل پرچم‌گذاری و تغییر کرد
- تغییر چه زمانی رخ داد و کدام دامنه خاص آن را دریافت کرد
- آیا وب‌سایت موفقیت را تأیید کرد و آیا نشست‌های فعال باطل شدند
- آیا تنظیمات امنیتی دیگر حساب دست‌خورده‌اند
- آیا کاربر اقدام را تأیید کرده است
- در صورت عدم کارکرد رمز جدید، کاربر باید چه کند
عامل باید در مواجهه با هر چیزی خارج از وظیفه محدود «تغییر رمز»، متوقف شده و موضوع را به کاربر ارجاع دهد. او نباید به‌طور مستقل تصمیم بگیرد که تغییر مجوزهای حساب یا پاسخ به سؤالات امنیتی، گام بعدی منطقی است.
الزامات کلیدی برای یک اجرای امن عبارتند از:
- جداسازی اعتبار: هوش مصنوعی هرگز نباید رمزهای متنی را در بافت، لاگ، حافظه یا تله‌متری دریافت کند. یک کارگزار اعتبارنامه مجزا باید اسرار را فقط در فیلدهای تأییدشده در یک منشأ تأییدشده پر کند.
- محدودیت شدید: عامل فقط رمز را تغییر دهد و هیچ تغییری در MFA، روش‌های بازیابی یا اطلاعات پروفایل ایجاد نکند.
- تأیید کاربر: یک بررسی بیومتریک اجباری (Face ID یا Touch ID) پیش از هر تغییر لازم است. تغییرات دسته‌ای باید نیاز به بررسی شفاف و محدودیت‌های منطقی داشته باشند.
- تأیید دقیق منشأ: سیستم باید وب‌سایت و حساب دقیق را تأیید کند و تغییر مسیرها و جریان‌های بین‌دامنه ای را با دقت بیشتری بررسی کند.
- مدیریت شکست: اپل باید کارکرد رمز جدید و ذخیره امن آن را تأیید کند، شکست‌های جزئی را به‌وضوح گزارش دهد و از حلقه‌های تکرار که منجر به قفل شدن حساب می‌شوند، بپرهیزد.
- تست مستقل: پژوهشگران باید برای تست تزریق پرامپت، تغییر مسیرهای مخرب، فرم‌های مبهم و سوءاستفاده از نشست‌های محلی هک‌شده تشویق شوند.
این قابلیت نمونه‌ای از ریسک اصلی هوش مصنوعی عامل‌محور است: خطر فقط یک جواب اشتباه نیست، بلکه این است که سیستم اجازه دارد با آن جواب چه کاری انجام دهد. وقتی یک AI می‌تواند کلیدهای زندگی دیجیتال شما را تغییر دهد، «معمولاً درست عمل کردن» یک مدل امنیتی ناکافی است.
گفتگو