برای محافظت از سیستم اصالتسنجیتان در Android، مدل مبتنی بر گذرواژه را کنار بگذارید، بهویژه برای حسابهای حساس مثل حسابهای بانکی و ایمیل کاربران. بهیاد داشته باشید که برخیاز برنامههایی که کاربران شما نصب میکنند ممکن است نیت خوبی نداشته باشند و سعی کنند از کاربران شما کلاهبرداری کنند.
همچنین، فرض نکنید که فقط کاربران مجاز از دستگاه استفاده خواهند کرد. سرقت تلفن مشکلی رایج است و مهاجمان دستگاههای قفلنشده را هدف قرار میدهند تا مستقیماً از دادههای کاربر یا برنامههای مالی سود ببرند. پیشنهاد میکنیم همه برنامههای حساس یک زماناتمام اصالتسنجی منطقی (۱۵ دقیقه؟) با درستیسنجی زیستسنجشی پیادهسازی کنند و قبلاز کنشهای حساس مانند انتقال وجه، اصالتسنجی بیشتری درخواست کنند.
کادر گفتگوی اصالتسنجی زیستسنجشی
کتابخانه «زیستسنجشی» مجموعهای از توابع را برای نمایش پیاموارهای ارائه میدهد که اصالتسنجی زیستسنجشی مانند تشخیص چهره یا تشخیص اثر انگشت را درخواست میکند. بااینحال، درخواستهای زیستسنجشی را میتوان طوری پیکربندی کرد که به LSKF برگردند، که خطرات شناختهشده دیدزنی اطلاعاتی را دارد. برای برنامههای حساس، توصیه میکنیم زیستسنجشی را به پین برنگردانید و پساز اتمام تلاشهای مجدد زیستسنجشی، کاربران میتوانند منتظر بمانند یا با گذرواژه دوباره به سیستم وارد شوند یا حسابها را بازنشانی کنند. بازنشانی حساب باید به عواملی نیاز داشته باشد که بهراحتی در دستگاه دردسترس نباشند (روال مطلوب در زیر).
چگونه این ویژگی به کاهش کلاهبرداری و سرقت تلفن کمک میکند
یک مورد استفاده خاص که میتواند برای جلوگیری از کلاهبرداری مفید باشد، درخواست اصالتسنجی زیستسنجشی در برنامه شما قبلاز تراکنش است. وقتی کاربران شما میخواهند تراکنش مالی انجام دهند، کادر گفتگوی زیستسنجشی نشان داده میشود تا تأیید شود که واقعاً کاربر موردنظر است که تراکنش را انجام میدهد. این روال مطلوب از دستگاه دربرابر مهاجمی که دستگاه را میدزدد محافظت میکند، صرفنظر از اینکه مهاجم «دانش مخفی صفحه قفل» را بداند یا نه، زیرا مهاجم باید ثابت کند که مالک دستگاه است.
برای سطوح امنیتی بیشتر، به توسعهدهندگان نرمافزار توصیه میکنیم «اصالتسنجی زیستسنجشی» کلاس ۳ را درخواست کنند و از CryptoObject برای تراکنشهای بانکی و مالی استفاده کنند.
پیادهسازی
- مطمئن شوید کتابخانه androidx.biometric را اضافه کردهاید.
- کادر گفتگوی ورود به سیستم زیستسنجشی را در فعالیت یا قطعهای که منطق موردنظر شما برای اصالتسنجی کاربر را دربردارد اضافه کنید.
کاتلین
private var executor: Executor? = null private var biometricPrompt: BiometricPrompt? = null private var promptInfo: BiometricPrompt.PromptInfo? = null fun onCreate(savedInstanceState: Bundle?) { super.onCreate(savedInstanceState) setContentView(R.layout.activity_login) executor = ContextCompat.getMainExecutor(this) biometricPrompt = BiometricPrompt(this@MainActivity, executor, object : AuthenticationCallback() { fun onAuthenticationError( errorCode: Int, @NonNull errString: CharSequence ) { super.onAuthenticationError(errorCode, errString) Toast.makeText( getApplicationContext(), "Authentication error: $errString", Toast.LENGTH_SHORT ) .show() } fun onAuthenticationSucceeded( @NonNull result: BiometricPrompt.AuthenticationResult? ) { super.onAuthenticationSucceeded(result) Toast.makeText( getApplicationContext(), "Authentication succeeded!", Toast.LENGTH_SHORT ).show() } fun onAuthenticationFailed() { super.onAuthenticationFailed() Toast.makeText( getApplicationContext(), "Authentication failed", Toast.LENGTH_SHORT ) .show() } }) promptInfo = Builder() .setTitle("Biometric login for my app") .setSubtitle("Log in using your biometric credential") .setNegativeButtonText("Use account password") .build() // Prompt appears when user clicks "Log in". // Consider integrating with the keystore to unlock cryptographic operations, // if needed by your app. val biometricLoginButton: Button = findViewById(R.id.biometric_login) biometricLoginButton.setOnClickListener { view -> biometricPrompt.authenticate( promptInfo ) } }
جاوا
private Executor executor; private BiometricPrompt biometricPrompt; private BiometricPrompt.PromptInfo promptInfo; @Override protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.activity_login); executor = ContextCompat.getMainExecutor(this); biometricPrompt = new BiometricPrompt(MainActivity.this, executor, new BiometricPrompt.AuthenticationCallback() { @Override public void onAuthenticationError(int errorCode, @NonNull CharSequence errString) { super.onAuthenticationError(errorCode, errString); Toast.makeText(getApplicationContext(), "Authentication error: " + errString, Toast.LENGTH_SHORT) .show(); } @Override public void onAuthenticationSucceeded( @NonNull BiometricPrompt.AuthenticationResult result) { super.onAuthenticationSucceeded(result); Toast.makeText(getApplicationContext(), "Authentication succeeded!", Toast.LENGTH_SHORT).show(); } @Override public void onAuthenticationFailed() { super.onAuthenticationFailed(); Toast.makeText(getApplicationContext(), "Authentication failed", Toast.LENGTH_SHORT) .show(); } }); promptInfo = new BiometricPrompt.PromptInfo.Builder() .setTitle("Biometric login for my app") .setSubtitle("Log in using your biometric credential") .setNegativeButtonText("Use account password") .build(); // Prompt appears when the user clicks "Log in". // Consider integrating with the keystore to unlock cryptographic operations, // if needed by your app. Button biometricLoginButton = findViewById(R.id.biometric_login); biometricLoginButton.setOnClickListener(view -> { biometricPrompt.authenticate(promptInfo); }); }
روالهای مطلوب
توصیه میکنیم با codelab شروع کنید تا درباره زیستسنجشی بیشتر بدانید.
بسته به موارد استفادهتان، میتوانید کادر گفتگو را با یا بدون کنش صریح کاربر پیادهسازی کنید. برای جلوگیری از کلاهبرداری، توصیه میکنیم برای هر تراکنش، گفتگوی زیستسنجشی را با کنش صریح کاربر اضافه کنید. میدانیم که افزودن اصالتسنجی میتواند باعث ایجاد اصطکاک در تجربه کاربری شود، اما بهدلیل ماهیت اطلاعاتی که در تراکنش بانکی پردازش میشود و اینکه اصالتسنجی زیستسنجشی روانتر از سایر روشهای اصالتسنجی است، فکر میکنیم که افزودن این سطح از پیمایش ضروری است.
درباره اصالتسنجی زیستسنجشی بیشتر بدانید.
گذرکلیدها
گذرکلید جایگزین ایمنتر و آسانتری برای گذرواژه است. گذرکلیدها از رمزنگاری کلید عمومی استفاده میکنند تا کاربران شما بتوانند بااستفاده از سازوکار قفل صفحه دستگاهشان (مانند اثر انگشت یا تشخیص چهره) به سیستم برنامهها و وبسایتها وارد شوند. این کار کاربر را از بهخاطر سپردن و مدیریت گذرواژهها بینیاز میکند و امنیت را بهطور قابلتوجهی بهبود میبخشد.
گذرکلیدها میتوانند الزامات اصالتسنجی چندعاملی را در یک مرحله برآورده کنند، و جایگزین گذرواژه و کدهای گذرواژه یکبارمصرف شوند تا محافظت قوی دربرابر حملات فیشینگ ارائه دهند و از تجربه کاربری ناخوشایند گذرواژههای یکبارمصرف مبتنی بر برنامه یا پیامک جلوگیری کنند. ازآنجاییکه گذرکلیدها استانداردسازی شدهاند، یک پیادهسازی واحد امکان تجربه بدون گذرواژه را در همه دستگاهها، مرورگرها، و سیستمعاملهای کاربران فراهم میکند.
در Android، گذرکلیدها بااستفاده از کتابخانه Jetpack مدیر اطلاعات کاربری پشتیبانی میشوند که روشهای اصلی اصالتسنجی، ازجمله گذرکلیدها، گذرواژهها، و ورود به سیستم فدرال (مانند «ورود به سیستم با Google») را یکپارچه میکند.
این کار چگونه به کاهش کلاهبرداری کمک میکند
گذرکلیدها از شما دربرابر حملات رمزگیری محافظت میکنند زیرا فقط در برنامهها و وبسایتهای ثبتشده شما کار میکنند.
مؤلفه اصلی گذرکلید یک کلید خصوصی رمزنگاریشده است. معمولاً این کلید خصوصی فقط در دستگاههای شما، مانند رایانه کیفی یا تلفن همراه، قرار دارد و توسط ارائهدهندگان اطلاعات کاربری (که بهعنوان مدیر گذرواژه نیز شناخته میشوند)، مانند «مدیر گذرواژه Google»، در سراسر آنها همگامسازی میشود. هنگام ایجاد گذرکلید، فقط کلید عمومی مربوطه توسط سرویس آنلاین ذخیره میشود. درطول ورود به سیستم، سرویس از کلید خصوصی برای امضای چالش از کلید عمومی استفاده میکند. این درخواست فقط میتواند از یکی از دستگاههای شما ارسال شده باشد. علاوهبراین، برای اینکه این اتفاق بیفتد، باید قفل دستگاه یا بخش ذخیره اعتبارنامهها را باز کنید، که این کار از ورودهای غیرمجاز به سیستم (برای مثال، ازطریق تلفن دزدیدهشده) جلوگیری میکند.
برای جلوگیری از دسترسی غیرمجاز درصورت بهسرقت رفتن دستگاه قفلبازشده، گذرکلیدها باید با پنجره زمانی معقولی برای اصالتسنجی همراه باشند. مهاجمی که دستگاهی را میدزدد نباید بتواند از برنامهای استفاده کند فقط به این دلیل که کاربر قبلی به سیستم وارد شده است. درعوض، اعتبارنامه باید در فواصل زمانی منظم (مثلاً هر ۱۵ دقیقه) منقضی شود و کاربران باید ملزم شوند هویتشان را ازطریق اصالتسنجی مجدد قفل صفحه تأیید کنند.
اگر تلفنتان دزدیده شود، گذرکلیدها از شما محافظت میکنند زیرا سارقان نمیتوانند گذرواژههایتان را برای استفاده در دستگاههای دیگر بدزدند – گذرکلیدها مختص دستگاه هستند. اگر از «مدیر گذرواژه Google» استفاده میکنید و تلفنتان بهسرقت رفته است، میتوانید از دستگاه دیگری (مثل رایانه) به سیستم «حساب Google» خود وارد شوید و ازراهدور از سیستم تلفن بهسرقترفته خارج شوید. این کار باعث میشود «مدیر گذرواژه Google» در تلفن بهسرقترفته، ازجمله گذرکلیدهای ذخیرهشده، غیرقابلاستفاده شود.
در بدترین حالت، اگر دستگاه دزدیدهشده بازیابی نشود، گذرکلیدها توسط ارائهدهنده اطلاعات اعتباری که گذرکلید را ایجاد و همگامسازی کرده است، به دستگاه جدید همگامسازی میشوند. برای مثال، ممکن است کاربر «مدیر گذرواژه Google» را برای ایجاد گذرکلید انتخاب کرده باشد و بتواند با ورود مجدد به سیستم «حساب Google» خود و ارائه قفل صفحه دستگاه قبلی، به گذرکلید خود در دستگاه جدید دسترسی پیدا کند.
در مقاله امنیت گذرکلیدها در «مدیر گذرواژه Google» بیشتر بدانید.
پیادهسازی
گذرکلیدها در دستگاههایی که Android 9 (سطح میانای برنامهسازی کاربردی ۲۸) یا بالاتر دارند پشتیبانی میشود. گذرواژهها و «ورود به سیستم با Google» از Android 4.4 به بعد پشتیبانی میشوند. برای شروع به کار با گذرکلیدها، این مراحل را دنبال کنید:
- کدلب Credential Manager را دنبال کنید تا درک اولیهای از نحوه پیادهسازی گذرکلیدها بهدست آورید.
- رهنمودهای طراحی تجربه کاربری گذرکلید را مرور کنید. این سند به شما نشان میدهد چه جریانهایی برای مورد استفاده شما توصیه میشود.
- با دنبال کردن راهنما، Credential Manager را مطالعه کنید.
- پیادهسازی «مدیر اطلاعات کاربری» و گذرکلیدها را برای برنامهتان برنامهریزی کنید. افزودن پشتیبانی از پیوندهای دارایی دیجیتال را برنامهریزی کنید.
برای جزئیات بیشتر درباره نحوه ایجاد، ثبت، و اصالتسنجی با گذرکلید، به اسناد توسعهدهنده ما مراجعه کنید.
بازنشانی حساب ایمن
مهاجم غیرمجازی که به دستگاه بازشده دسترسی دارد (مثلاً وقتی تلفن ربوده میشود) تلاش میکند به برنامههای حساس، بهویژه برنامههای بانکی یا نقدی، دسترسی پیدا کند. اگر برنامه درستیسنجی زیستسنجشی را پیادهسازی کند، مهاجم سعی میکند حساب را بازنشانی کند تا بتواند وارد شود. بسیار مهم است که جریان بازنشانی حساب صرفاً به اطلاعاتی که بهراحتی در دستگاه قابلدسترسی است، مانند ایمیل یا پیوندهای بازنشانی گذرواژه یکبارمصرف پیامکی، متکی نباشد.
در اینجا روالهای مطلوب رایجی آورده شده است که میتوانید در جریان بازنشانی برنامهتان بگنجانید:
- تشخیص چهره، علاوهبر گذرواژه یکبارمصرف
- سؤالات امنیتی
- عامل دانش (مانند نام خانوادگی مادر پیشاز ازدواج، شهر محل تولد، یا آهنگ موردعلاقه)
- درستیسنجی با مدرک شناسایی
SMS Retriever API
SMS Retriever API به شما امکان میدهد درستیسنجی کاربر مبتنی بر پیامک را بهطور خودکار در برنامه Android خود انجام دهید. به این ترتیب، کاربر نیازی به تایپ دستی کدهای درستیسنجی نخواهد داشت. علاوهبراین، این میانای برنامهسازی کاربردی از کاربر
اجازههای برنامه اضافی و بالقوه خطرناک مثل RECEIVE_SMS یا
READ_SMS را درخواست نمیکند. بااینحال، برای محافظت دربرابر دسترسی محلی غیرمجاز به دستگاه، نباید از پیامک بهعنوان تنها روش درستیسنجی کاربر استفاده شود.
این کار چگونه به کاهش کلاهبرداری کمک میکند
برخیاز کاربران از کدهای پیامکی بهعنوان تنها عامل اصالتسنجی خود استفاده میکنند که این امر نقطه ورود آسانی برای کلاهبرداری فراهم میکند.
SMS Retriever API به برنامه اجازه میدهد کد پیامک را مستقیماً بدون تعامل کاربر بازیابی کند و میتواند سطحی از محافظت دربرابر کلاهبرداری را ارائه دهد.
پیادهسازی
پیادهسازی SMS Retriever API دو بخش دارد: Android و سرور.
Android: (راهنما)
- شماره تلفن کاربر را دریافت کنید.
- کارخواه بازیابی پیامک را شروع کنید.
- شماره تلفن را به سرورتان ارسال کنید.
- پیامهای درستیسنجی را دریافت کنید.
- گذرواژه یکبارمصرف را به سرورتان ارسال کنید.
سرور: (راهنما)
- پیام درستیسنجی بسازید.
- پیام درستیسنجی را ازطریق پیامک ارسال کنید.
- گذرواژه یکبارمصرف را پساز دریافت درستیسنجی کنید.
روالهای مطلوب
وقتی برنامه ادغام شد و شماره تلفن کاربر با SMS Retriever API درستیسنجی شد، سعی میکند گذرواژه یکبارمصرف را دریافت کند. اگر موفقیتآمیز باشد، این نشانهای قوی است که پیامک بهطور خودکار در دستگاه دریافت شده است. اگر این کار موفقیتآمیز نباشد و کاربر مجبور شود گذرواژه یکبارمصرف را بهصورت دستی تایپ کند، این میتواند نشانهای هشداردهنده باشد که کاربر ممکن است درمعرض کلاهبرداری قرار گرفته باشد.
نباید از پیامک بهعنوان تنها سازوکار درستیسنجی کاربر استفاده شود زیرا فضا را برای حملات محلی، مثل حملهای که در آن مهاجم دستگاه بازشده را میرباید، یا حملات شبیهسازی سیمکارت باز میگذارد. توصیه میشود هروقت ممکن بود از «زیستسنجشی» استفاده کنید. در دستگاههایی که حسگرهای زیستسنجشی دردسترس نیستند، اصالتسنجی کاربر باید حداقل به یک عامل متکی باشد که بهراحتی از دستگاه فعلی قابلدستیابی نباشد.
بیشتر بدانید
برای مطالعه بیشتر درباره روالهای مطلوب، منابع زیر را بررسی کنید:
- اسناد Android ما درباره «امنیت»
- مستندات Play Integrity API
- تغییرات Android 15
- روالهای مطلوب برای جلوگیری از تماسهای فریبکارانه از Monzo Bank