تخزين الرموز السرية في تطبيقات الموبايل: Android Keystore وiOS Keychain

ما الذي يُعد سرًا داخل تطبيق الموبايل؟

ليست كل البيانات المخزنة متساوية في حساسيتها. إعدادات الواجهة، واللغة، وحالة الشاشة المؤقتة لا تحتاج عادةً إلى الحماية نفسها التي تحتاجها بيانات الاعتماد. تشمل الأسرار المحتملة access tokens وrefresh tokens ومفاتيح التشفير الخاصة بالمستخدم وبيانات اعتماد الأجهزة. أما كلمات المرور، فمن الأفضل عمومًا ألا يحتفظ بها التطبيق أصلًا؛ استخدم تدفق مصادقة مناسبًا بدلًا من إعادة تخزين كلمة المرور.

القاعدة العملية هي تصنيف البيانات قبل اختيار مكان التخزين. اسأل: هل تسمح هذه القيمة بانتحال هوية المستخدم؟ هل يمكن استخدامها للوصول إلى بيانات أخرى؟ هل لها صلاحية قصيرة؟ هل يمكن إبطالها عن بُعد؟ كلما زادت قدرة القيمة على منح الوصول، زادت ضرورة تقليل تعرضها وتقليل مدة استخدامها.

التخزين العادي ليس خزنة أسرار

تُستخدم SharedPreferences وملفات الإعدادات وقواعد البيانات المحلية لتخزين بيانات التطبيق، لكنها ليست بديلًا مباشرًا عن مخازن الأسرار. وقد تُنسخ البيانات إلى نسخ احتياطية أو تظهر في سجلات التصحيح أو تصبح قابلة للقراءة في ظروف اختراق الجهاز. وحتى لو كان الملف داخل مجلد التطبيق، فهذا لا يضمن حمايته في كل نموذج تهديد.

تشفير الملف قد يساعد، لكن السؤال الحاسم هو أين يوجد مفتاح التشفير. إذا كان المفتاح الثابت مضمّنًا داخل التطبيق، يستطيع مهاجم يملك التطبيق تحليله واستخراجه أو استدعاء الكود لفك البيانات. لذلك يجب أن يكون المفتاح مُدارًا من النظام، لا سلسلة سرية مخبأة في المصدر.

Android Keystore: إدارة المفاتيح بدل تخزين النصوص

يوفر Android Keystore واجهة لإنشاء مفاتيح تشفير وإدارتها بحيث لا يحتاج التطبيق إلى قراءة مادة المفتاح الخاصة مباشرة. وقد تكون المفاتيح محمية ببيئة تنفيذ موثوقة أو عتاد آمن بحسب الجهاز وقدراته. لا تفترض أن كل هاتف يملك المستوى العتادي نفسه؛ افحص القدرات عند الحاجة وصمّم سلوكًا بديلًا مناسبًا.

من المهم التمييز بين Keystore ومخزن القيمة نفسها. غالبًا ما يُستخدم Keystore لحماية مفتاح يُشفّر به عنصر حساس محفوظ في تخزين التطبيق، بينما قد تستخدم مكتبة موثوقة تخزينًا آمنًا يربط القيمة بآلية النظام. لا يعني اسم Keystore أن بإمكانك وضع أي نص فيه كأنه قاعدة بيانات عامة.

اختيار القيود المناسبة للمفتاح

عند إنشاء مفتاح، قرر الغرض منه وخوارزميته وما إذا كان يتطلب مصادقة المستخدم، وما إذا كان يمكن تصديره أو استخدامه فقط داخل العمليات المسموح بها. لا تفرض طلب بصمة لكل عملية صغيرة بلا سبب؛ فهذا قد يضر تجربة الاستخدام ويدفع الفريق إلى حلول التفافية. وفي المقابل، العمليات عالية الحساسية قد تحتاج إلى مصادقة حديثة.

عند تغيير سياسة المفتاح أو ترقية التطبيق، خطط للتعامل مع المفاتيح القديمة. فقد لا يكون المفتاح متاحًا بعد إعادة ضبط الجهاز أو إزالة قفل الشاشة أو تغير حالة المصادقة، وفقًا للقيود المختارة. تعامل مع فشل فك التشفير بوصفه حالة متوقعة تستدعي حذف البيانات القديمة أو إعادة تسجيل الدخول، لا بوصفه سببًا لتكرار المحاولة بلا نهاية.

iOS Keychain: تخزين بيانات الاعتماد مع سياسة وصول

يُستخدم Keychain في iOS وiPadOS لتخزين عناصر صغيرة حساسة مثل الرموز وبيانات الاعتماد والمفاتيح. تتيح خصائص الوصول تحديد متى يمكن قراءة العنصر، وما إذا كان مرتبطًا بالجهاز أو قابلًا للمزامنة عبر الأجهزة، وما إذا كان يتطلب حضور المستخدم. يجب أن يتوافق الاختيار مع حاجة المنتج: لا تفعّل المزامنة لمجرد أنها متاحة إذا كان نسخ السر إلى جهاز آخر غير مرغوب.

اختيار مستوى الحماية قرار منتج وأمن معًا. فالعنصر الذي يجب أن يبقى متاحًا بعد إعادة تشغيل الهاتف يختلف عن عنصر لا يُقرأ إلا والجهاز مفتوح. اقرأ توثيق Apple الخاص بفئات Keychain وسمات الوصول قبل اختيار الإعدادات النهائية، واختبر السلوك على إصدارات النظام التي تدعمها.

حالات حذف التطبيق وإعادة التثبيت

لا تبنِ افتراضات غير مختبرة حول بقاء عناصر Keychain أو اختفائها بعد حذف التطبيق وإعادة تثبيته؛ يعتمد السلوك على نوع العنصر وإعداداته وسياق النظام. إذا كان المنتج يتطلب تسجيل خروج كاملًا، فاحذف العناصر التي تملكها صراحةً وأبطل الجلسة من الخادم. كما ينبغي أن يوضح الاختبار ما يحدث عند استعادة نسخة احتياطية أو نقل المستخدم إلى جهاز جديد.

صمّم دورة حياة الرمز من تسجيل الدخول إلى الإبطال

التخزين الآمن ليس سوى جزء من دورة حياة الاعتماد. يبدأ التصميم عند تسجيل الدخول: يصدر الخادم رمزًا محدود الصلاحية، ويحدد صلاحياته، ويقرر آلية تجديده وإبطاله. ينبغي ألا يحصل التطبيق على صلاحيات أوسع مما يحتاجه، وألا يكون access token طويل العمر لمجرد تسهيل البرمجة. يمكن أن يكون access token قصير العمر بينما يحتفظ التطبيق بـ refresh token في التخزين الآمن لتجديد الجلسة وفق سياسة الخادم.

عند التجديد، أرسل الطلب عبر TLS وتحقق من الاستجابة، ثم استبدل القيمة القديمة بالجديدة بطريقة لا تترك التطبيق في حالة ملتبسة. إذا كان الخادم يدعم تدوير refresh tokens، فعليه إبطال الرمز السابق عند استخدام الجديد ورصد إعادة استخدام رمز قديم وفق تصميم الجلسات. أما التطبيق، فعليه حفظ القيمة الجديدة قبل متابعة العمليات التي تعتمد عليها، والتعامل مع انقطاع الشبكة دون طباعة الرموز في السجل.

تسجيل الخروج يجب أن يشمل الخادم والجهاز

حذف الرمز محليًا يمنع التطبيق الطبيعي من استخدامه، لكنه لا يبطل نسخة مسروقة سبق نسخها. لذلك يجب أن يرسل تسجيل الخروج طلب إبطال إلى الخادم عندما يكون ذلك ممكنًا، ثم يحذف القيم المحلية حتى إذا فشل الاتصال، وفق سياسة واضحة لا تعيد إظهار الجلسة تلقائيًا. يمكن عرض رسالة تفيد بأن الإبطال البعيد تعذر إكماله، مع آلية إعادة محاولة لا تكشف الرمز.

يجب أيضًا تحديد سلوك انتهاء الصلاحية. إذا أعاد الخادم 401، فلا تكرر الطلب بلا حدود ولا تحاول تجديد الجلسة في حلقة. نفّذ محاولة تجديد واحدة وفق سياسة معروفة، ثم أعد الطلب الأصلي مرة واحدة فقط إذا كان آمنًا لإعادة التنفيذ. إذا فشل التجديد، امسح الاعتمادات واطلب تسجيل الدخول من جديد.

تنفيذ عملي: أنشئ طبقة تخزين صغيرة وواضحة

حتى إذا اختلفت مكتبات Android وiOS أو إطار العمل مثل Flutter وReact Native، فإن واجهة التطبيق الداخلية ينبغي أن تبقى محدودة: قراءة الرمز، حفظه، حذفه، وربما التحقق من وجوده. لا تجعل كل شاشة تصل مباشرة إلى Keychain أو SharedPreferences؛ هذا يصعّب المراجعة الأمنية ويزيد احتمال نسيان حذف قيمة في مسار استثنائي.

يمكن تمثيل الواجهة بمفهوم عام كما يلي. هذا مثال شبه برمجي لتوضيح المسؤوليات، وليس مكتبة جاهزة للنسخ:

interface SecureCredentialStore {
  readRefreshToken(): Promise<string | null>;
  saveRefreshToken(token: string): Promise<void>;
  clearCredentials(): Promise<void>;
}

تستخدم طبقة المصادقة هذه الواجهة فقط. أما التنفيذ الأصلي لكل منصة فيختار Keychain أو مكتبة Android موثوقة تعتمد Keystore، مع إعدادات وصول مناسبة. لا تضف وظيفة تصدير الرموز أو طباعتها لأغراض التشخيص. وإذا احتجت إلى فحص الحالة، فسجّل حدثًا مثل “credential_missing” دون تسجيل القيمة نفسها.

التعامل مع الأخطاء بصورة آمنة

قد يفشل التخزين بسبب امتلاء المساحة، أو تغيّر حالة قفل الجهاز، أو حذف المفتاح، أو خطأ في التهيئة. عالج هذه الحالات باعتبارها نتائج متوقعة. لا تنتقل تلقائيًا إلى تخزين نصي غير محمي عند فشل التخزين الآمن؛ فهذا يحوّل عطلًا ظاهرًا إلى ثغرة صامتة. الأفضل إيقاف ميزة الاحتفاظ بتسجيل الدخول وشرح أن المستخدم قد يحتاج إلى تسجيل الدخول مجددًا.

كذلك تجنب تخزين أكثر من نسخة للرمز في الذاكرة والملفات وقاعدة البيانات. احتفظ به في أقل عدد من الأماكن، وقلّل عمره في الذاكرة قدر الإمكان. لا يمكن ضمان محو كل نسخة من ذاكرة العملية في بيئات اللغات المُدارة، لكن يمكن تجنب النسخ غير الضرورية وعدم إبقاء القيم في كائنات طويلة العمر.

اختبارات يجب أن تسبق الإطلاق

اختبر تدفق المصادقة على أجهزة حقيقية ومحاكيات بإصدارات مختلفة، لكن لا تعتمد على المحاكي وحده لخصائص العتاد الآمن. أنشئ حالات اختبار واضحة تشمل أول تسجيل دخول، إعادة تشغيل الجهاز، قفل الشاشة وفتحها، انتهاء الرمز، تجديد الرمز، انقطاع الشبكة، تسجيل الخروج، حذف الحساب، وتغيير كلمة المرور من جهاز آخر.

اختبر أيضًا استعادة النسخ الاحتياطية ونقل الحساب إلى جهاز جديد، مع مراعاة أن السلوك يختلف حسب المنصة وإعدادات الوصول. يجب أن تعرف النتيجة المتوقعة لكل حالة: هل يظل الرمز قابلًا للقراءة؟ هل يتطلب الأمر مصادقة؟ هل يجب على المستخدم تسجيل الدخول من جديد؟ وثّق القرار بدل تركه لسلوك غير مقصود في مكتبة التخزين.

قائمة مراجعة أمنية قبل النشر

• لا توجد رموز أو كلمات مرور في السجلات أو تقارير الأعطال أو لقطات الشاشة التشخيصية.
• تستخدم الاتصالات TLS وتتحقق من شهادات الخادم بصورة طبيعية، دون تعطيل التحقق في الإنتاج.
• الرموز محدودة الصلاحية والصلاحيات، ويمكن إبطال الجلسات من الخادم.
• تُحذف بيانات الاعتماد المحلية عند تسجيل الخروج أو فشل التجديد النهائي.
• لا توجد مفاتيح ثابتة أو رموز حقيقية داخل المستودع أو ملفات الإعدادات.
• تُختبر حالات فشل التخزين ولا ينتج عنها انتقال صامت إلى تخزين غير آمن.
• تراجع المكتبات المستخدمة وصلاحياتها وتحديثاتها قبل إصدار النسخة.

لا تختبر فقط المسار السعيد. الاختبار الأكثر قيمة غالبًا هو ما يحدث عندما تكون القيمة مفقودة أو تالفة أو غير قابلة للفك أو مرفوضة من الخادم. راجع أيضًا مبدأ الدفاع متعدد الطبقات لفهم كيف تكمل حماية العميل ضوابط الخادم، وراجع مراقبة أخطاء تطبيقات الموبايل لتصميم تشخيص لا يكشف البيانات الحساسة.

أخطاء شائعة وتوصيات نهائية

من الأخطاء الشائعة تخزين رمز الدخول في قاعدة البيانات المحلية لمجرد أن الوصول إليها سهل، أو تشفيره بمفتاح مضمن، أو الاعتماد على البصمة وحدها باعتبارها بديلًا عن إدارة الجلسات. كذلك لا يكفي إخفاء الزر أو التحقق من الصلاحية في واجهة التطبيق؛ يجب أن يتحقق الخادم من كل طلب ويطبق صلاحياته بنفسه.

ابدأ بجرد البيانات، ثم اختر مخزن النظام المناسب، ولفّه في واجهة صغيرة، وقلل عمر الرموز، ونفّذ الإبطال من جهة الخادم، وأضف اختبارات للحالات الاستثنائية. إذا كانت متطلبات المنتج لا تسمح بتخزين دائم آمن في بعض الأجهزة، فاختر إعادة تسجيل الدخول بدل التضحية بالحماية. الأمان الجيد ليس إعدادًا واحدًا، بل مجموعة قرارات متسقة يمكن شرحها واختبارها وصيانتها.

اختيار المكتبة وتوثيق القرار

في التطبيقات متعددة المنصات، لا تكتب طبقة تشفير خاصة بك إلا إذا كانت لديك خبرة ومراجعة متخصصة تبرر ذلك. ابدأ بواجهات النظام أو مكتبة موثوقة نشطة الصيانة، واقرأ توثيقها حول النسخ الاحتياطي والهجرة وإمكانية الوصول إلى البيانات. سجّل سبب اختيار كل إعداد، والتهديد الذي يعالجه، وأثره على تجربة المستخدم، حتى يستطيع الفريق مراجعته عند تغير المتطلبات.

وأخيرًا، افصل بين حماية البيانات على الجهاز وصحة صلاحيات الحساب. لا تجعل وجود refresh token دليلًا على أن المستخدم ما زال مخولًا لكل عملية؛ فقد تتغير صلاحياته أو تُقفل الجلسة على الخادم. اجعل الخادم صاحب القرار النهائي، واستخدم التخزين المحلي لتقليل الاحتكاك لا لتجاوز التحقق.

خطة تطبيق من أربع مراحل

لتطبيق هذه المبادئ دون تعقيد المشروع، قسّم العمل إلى مراحل. أولًا، احصر كل قيمة حساسة وحدد مصدرها وصلاحيتها ومكان استخدامها. ثانيًا، أنشئ طبقة واحدة للتخزين الآمن واختر سياسة الوصول المناسبة لكل منصة. ثالثًا، اربط التجديد وتسجيل الخروج بإبطال الخادم، مع معالجة واضحة لانتهاء الصلاحية. رابعًا، أضف اختبارات آلية ويدوية تغطي حالات الفشل قبل الإطلاق وبعد كل تحديث كبير.

راجع السياسة دوريًا، خصوصًا عند إضافة مزود تسجيل دخول جديد أو دعم أجهزة مشتركة أو ميزات تعمل دون اتصال. إذا كانت هناك حاجة لتخزين بيانات حساسة أخرى، مثل مفاتيح تشفير ملفات المستخدم، فتعامل معها كحالة منفصلة بدل إعادة استخدام إعدادات رمز الدخول تلقائيًا. الهدف هو تقليل الأسرار وتقليل عدد الأماكن التي يمكن أن تظهر فيها، مع الحفاظ على سلوك يمكن للمستخدم فهمه.

What Counts as a Secret in a Mobile App?

Not every stored value has the same sensitivity. UI preferences, language choices, and temporary screen state usually do not need the same protection as credentials. Potential secrets include access tokens, refresh tokens, user-specific encryption keys, and device credentials. Passwords generally should not be retained by the app at all; prefer an appropriate authentication flow instead of storing the password again.

A practical rule is to classify data before choosing storage. Ask whether a value can impersonate the user, unlock other data, has a short lifetime, or can be revoked remotely. The more access a value grants, the more important it is to minimize exposure and reduce how long it remains useful.

Ordinary App Storage Is Not a Secret Vault

SharedPreferences, configuration files, and local databases are useful for app data, but they are not direct substitutes for a secret store. Data may be copied into backups, exposed through debug logs, or become readable under a device-compromise threat model. Being inside the app’s private directory is not a guarantee under every attack scenario.

Encrypting a file can help, but the decisive question is where the encryption key lives. If a fixed key is embedded in the app, an attacker who has the app can analyze it, extract the key, or invoke the decryption code. The key should be managed by the operating system rather than hidden as a source-code string.

Android Keystore: Manage Keys, Not Arbitrary Text

Android Keystore provides APIs for generating and managing cryptographic keys so an app does not need to read private key material directly. Depending on the device, keys may be protected by a trusted execution environment or secure hardware. Do not assume every phone offers the same hardware-backed level; check capabilities when required and design a reasonable fallback.

It is important to distinguish Keystore from the storage of the value itself. Keystore is often used to protect a key that encrypts a sensitive item stored in app storage, while a trusted library may combine secure storage with platform facilities. The name Keystore does not mean that arbitrary text can be stored there like rows in a general-purpose database.

Choose Key Restrictions Deliberately

When creating a key, define its purpose, algorithm, whether user authentication is required, and whether it can be exported or only used for permitted operations. Requiring a biometric prompt for every minor action without a clear reason can harm usability and encourage workarounds. Conversely, high-risk operations may justify recent user authentication.

Plan for old keys when policies change or the app is upgraded. A key may become unavailable after a device reset, lock-screen change, or authentication-state change, depending on its constraints. Treat decryption failure as an expected state that may require deleting stale data or signing in again, not as a reason to retry forever.

iOS Keychain: Credentials With an Access Policy

Keychain on iOS and iPadOS stores small sensitive items such as tokens, credentials, and keys. Accessibility attributes can define when an item may be read, whether it is device-bound or synchronizable across devices, and whether user presence is required. The right choice follows product requirements: do not enable synchronization simply because it is available if copying the secret to another device is undesirable.

Protection level is both a product and security decision. An item that must remain available after a reboot differs from one that should be readable only while the device is unlocked. Consult Apple’s documentation on Keychain classes and accessibility attributes before finalizing settings, and test the behavior across supported OS versions.

App Removal and Reinstallation

Do not make untested assumptions about whether Keychain items survive app deletion and reinstallation; behavior depends on item type, attributes, and system context. If the product requires a complete sign-out, explicitly delete the items it owns and revoke the server session. Tests should also cover backup restoration and moving the user to a new device.

Design the Token Lifecycle From Login to Revocation

Secure storage is only one part of credential lifecycle management. The design begins at login: the server issues a token with limited lifetime and scope, and defines how it can be refreshed and revoked. The app should receive no more privilege than it needs, and an access token should not be long-lived merely to simplify implementation. A common pattern uses a short-lived access token and a refresh token held in secure storage, with renewal governed by server policy.

During refresh, send the request over TLS, validate the response, and replace the old value without leaving the app in an ambiguous state. If the server supports refresh-token rotation, it should invalidate the previous token when issuing a new one and detect reuse of an old token according to the session design. The app should persist the new value before continuing dependent operations and must never print tokens when network calls fail.

Logout Should Address Both Server and Device

Deleting a local token prevents the normal app from using it, but it does not invalidate a copy that was stolen earlier. Therefore, logout should request server-side revocation when possible, then remove local credentials even if the network request fails, according to a policy that does not silently restore the session. The UI can explain when remote revocation could not be completed, with a retry path that never exposes the token.

Define expiration behavior as well. If the server returns 401, do not repeat the request forever or refresh in a loop. Perform one refresh attempt under a documented policy, then retry the original request once only if it is safe to repeat. If refresh fails, clear credentials and require the user to sign in again.

Practical Implementation: Keep the Storage Abstraction Small

Even when Android and iOS libraries differ, or the app uses a framework such as Flutter or React Native, the internal interface should remain small: read a token, save it, delete it, and perhaps check whether one exists. Do not let every screen access Keychain or SharedPreferences directly. That makes security review harder and increases the chance that an exceptional path forgets to remove a value.

The following conceptual interface illustrates the responsibilities. It is pseudocode, not a drop-in library:

interface SecureCredentialStore {
  readRefreshToken(): Promise<string | null>;
  saveRefreshToken(token: string): Promise<void>;
  clearCredentials(): Promise<void>;
}

The authentication layer uses this interface only. Each platform implementation chooses Keychain or a trusted Android library backed by Keystore, with appropriate access controls. Do not add an export or print-token function for diagnostics. If you need state visibility, log an event such as “credential_missing” without logging the value itself.

Fail Safely

Storage can fail because of device state, a missing key, initialization errors, or platform policy. Treat these as expected outcomes. Do not silently fall back to unprotected text storage when secure storage fails; that turns a visible failure into a hidden vulnerability. Prefer disabling persistent sign-in and explaining that the user may need to authenticate again.

Also avoid keeping multiple copies of the token across memory, files, and a database. Store it in as few places as possible and minimize its lifetime in memory. Managed runtimes cannot promise that every memory copy is immediately erased, but the app can avoid unnecessary copies and long-lived objects that retain credentials.

Tests to Run Before Release

Test authentication on real devices and emulators across supported OS versions, but do not rely on an emulator alone for hardware-backed security properties. Build explicit cases for first login, device reboot, screen lock and unlock, token expiry, token refresh, network loss, logout, account deletion, and a password change from another device.

Also test backup restoration and account migration to a new device, remembering that behavior depends on platform and accessibility settings. Every case should have an expected outcome: can the token still be read, is user authentication required, or must the user sign in again? Document the decision instead of leaving it to accidental library behavior.

Pre-Release Security Checklist

• No tokens or passwords appear in logs, crash reports, or diagnostic screenshots.
• Network connections use TLS and normal certificate validation; production builds do not disable validation.
• Tokens have limited lifetime and scope, and sessions can be revoked server-side.
• Local credentials are cleared after logout or final refresh failure.
• No fixed keys or real tokens are committed to the repository or configuration files.
• Storage failures are tested and never cause a silent fallback to insecure storage.
• Dependencies, permissions, and update status are reviewed before release.

Do not test only the happy path. The most valuable test is often what happens when a value is missing, corrupted, undecryptable, or rejected by the server. Also review defense in depth to understand how client protections complement server controls, and mobile app crash reporting for diagnostics that avoid sensitive data.

Common Mistakes and Final Recommendations

Common mistakes include storing a token in a local database because it is convenient, encrypting it with a hard-coded key, or treating biometrics as a substitute for session management. Hiding a button or checking authorization only in the UI is also insufficient; the server must validate every request and enforce permissions independently.

Start by inventorying the data, choose the appropriate platform store, wrap it in a small interface, minimize token lifetime, implement server-side revocation, and test exceptional cases. If product requirements cannot support persistent secure storage on a device, prefer requiring sign-in again over weakening protection. Good security is not one setting; it is a consistent set of decisions that can be explained, tested, and maintained.

Choose a Library and Document the Decision

For cross-platform apps, avoid writing a custom cryptographic storage layer unless specialist expertise and review justify it. Start with platform APIs or a trusted, actively maintained library, and read its guidance on backups, migration, and accessibility. Document why each setting was selected, which threat it addresses, and how it affects the user experience so the team can revisit the decision when requirements change.

Finally, separate device data protection from account authorization. Possessing a refresh token must not prove that a user is still permitted to perform every operation; permissions can change and sessions can be locked server-side. Keep the server as the final authority, and use local storage to reduce friction, never to bypass validation.