Autenticazione sicura degli utenti

Per proteggere il sistema di autenticazione in Android, valuta la possibilità di abbandonare un modello basato su password, soprattutto per gli account sensibili come quelli bancari ed email degli utenti. Ricorda che alcune app installate dagli utenti potrebbero non avere le migliori intenzioni e potrebbero tentare di fare phishing.

Inoltre, non dare per scontato che solo gli utenti autorizzati utilizzeranno il dispositivo. Il furto di smartphone è un problema comune e i malintenzionati prendono di mira i dispositivi sbloccati per trarre profitto direttamente dai dati degli utenti o dalle app finanziarie. Suggeriamo a tutte le app sensibili di implementare un timeout di autenticazione ragionevole (15 minuti?) con verifica biometrica e richiedere un'autenticazione aggiuntiva prima di azioni sensibili come i trasferimenti di denaro.

Finestra di dialogo dell'autenticazione biometrica

La libreria Biometrics offre un insieme di funzioni per visualizzare un prompt che richiede l'autenticazione biometrica, ad esempio il riconoscimento facciale o dell'impronta. Tuttavia, i prompt biometrici possono essere configurati per il fallback a LSKF, che presenta rischi noti di shoulder surfing. Per le app sensibili, consigliamo di non eseguire il fallback biometrico al PIN e, dopo aver esaurito i tentativi biometrici, gli utenti possono attendere o accedere nuovamente con la password o reimpostare gli account. Il ripristino dell'account deve richiedere fattori non facilmente accessibili sul dispositivo (best practice di seguito).

In che modo questo contribuisce a mitigare le frodi e il furto di smartphone

Un caso d'uso particolare che può essere utile per prevenire le frodi è richiedere l'autenticazione biometrica all'interno dell'app prima di una transazione. Quando gli utenti vogliono effettuare una transazione finanziaria, viene visualizzata la finestra di dialogo biometrica per verificare che sia effettivamente l'utente previsto a effettuare la transazione. Questa best practice proteggerebbe da un aggressore che ruba un dispositivo indipendentemente dal fatto che l'aggressore conosca o meno la LSKF, poiché dovrà dimostrare di essere il proprietario del dispositivo.

Per ulteriori livelli di sicurezza, consigliamo agli sviluppatori di app di richiedere l'autenticazione biometrica di classe 3 e di utilizzare CryptoObject per le transazioni bancarie e finanziarie.

Implementazione

1. Assicurati di includere la libreria androidx.biometric.
2. Includi la finestra di dialogo di accesso biometrico nell'attività o nel fragment che contiene la logica per cui vuoi che l'utente venga autenticato.

Kotlin

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
    )
  }
}

Java

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);
    });
}

Best practice

Ti consigliamo di iniziare con il codelab per saperne di più sulla biometria.

A seconda dei casi d'uso, puoi implementare la finestra di dialogo con o senza un'azione esplicita dell'utente. Per evitare frodi, ti consigliamo di aggiungere la finestra di dialogo biometrica con un'azione esplicita dell'utente per ogni transazione. Siamo consapevoli che l'aggiunta dell'autenticazione può introdurre attrito nell'esperienza utente, ma data la natura delle informazioni gestite in una transazione bancaria e il fatto che l'autenticazione biometrica sia più fluida rispetto ad altri metodi di autenticazione, riteniamo necessario aggiungere questo livello di navigazione.

Scopri di più sull'autenticazione biometrica.

Passkey

Le passkey sono un'alternativa più sicura e semplice rispetto alle password. Le passkey utilizzano la crittografia a chiave pubblica per consentire agli utenti di accedere ad app e siti web utilizzando il meccanismo di blocco schermo del dispositivo, ad esempio il riconoscimento dell'impronta o del volto. In questo modo, l'utente non deve ricordare e gestire le password e la sicurezza viene migliorata in modo significativo.

Le passkey possono soddisfare i requisiti di autenticazione a più fattori in un unico passaggio, sostituendo sia una password sia i codici OTP per offrire una protezione efficace contro gli attacchi di phishing ed evitare l'esperienza utente problematica delle password usa e getta basate su SMS o app. Poiché le passkey sono standardizzate, una singola implementazione consente un'esperienza senza password su tutti i dispositivi, i browser e i sistemi operativi degli utenti.

Su Android, le passkey sono supportate tramite la libreria Jetpack Gestore delle credenziali, che unifica i principali metodi di autenticazione, tra cui passkey, password e accesso federato (ad esempio Accedi con Google).

Come contribuisce a mitigare le frodi

Le passkey ti proteggono dagli attacchi di phishing perché funzionano solo sulle app e sui siti web registrati.

Il componente principale di una passkey è una chiave privata crittografica. In genere, questa chiave privata risiede esclusivamente sui tuoi dispositivi, come laptop o cellulari, e viene sincronizzata tra loro dai fornitori di credenziali (noti anche come gestori delle password), come Gestore delle password di Google. Quando viene creata una passkey, il servizio online salva solo la chiave pubblica corrispondente. Durante l'accesso, il servizio utilizza la chiave privata per firmare una richiesta dalla chiave pubblica. Può provenire solo da uno dei tuoi dispositivi. Inoltre, per far sì che ciò avvenga, devi sbloccare il dispositivo o l'archivio delle credenziali, il che impedisce accessi non autorizzati (ad esempio, da uno smartphone rubato).

Per impedire l'accesso non autorizzato in caso di furto di un dispositivo sbloccato, le passkey devono essere abbinate a un intervallo di timeout di autenticazione ragionevole. Un malintenzionato che ruba un dispositivo non dovrebbe essere in grado di utilizzare un'applicazione solo perché l'utente precedente aveva eseguito l'accesso. Al contrario, le credenziali devono scadere a intervalli regolari (ad esempio ogni 15 minuti) e gli utenti devono verificare la propria identità tramite la riautenticazione del blocco schermo.

Se lo smartphone viene rubato, le passkey ti proteggono perché i ladri non possono rubare le tue password per utilizzarle su altri dispositivi. Le passkey sono specifiche per il dispositivo. Se utilizzi Gestore delle password di Google e ti viene rubato lo smartphone, puoi accedere al tuo Account Google da un altro dispositivo (ad esempio un computer) e uscire da remoto dallo smartphone rubato. In questo modo, Gestore delle password di Google sullo smartphone rubato diventa inutilizzabile, incluse le passkey salvate.

Nel peggiore dei casi, se il dispositivo rubato non viene recuperato, le passkey vengono risincronizzate sul nuovo dispositivo dal fornitore di credenziali che ha creato e sincronizzato la passkey. Ad esempio, l'utente potrebbe aver scelto Gestore delle password di Google per creare la passkey e può accedere alla passkey su un nuovo dispositivo accedendo di nuovo al proprio Account Google e fornendo il blocco schermo del dispositivo precedente.

Scopri di più nell'articolo Sicurezza delle passkey in Gestore delle password di Google.

Implementazione

Le passkey sono supportate sui dispositivi con Android 9 (livello API 28) o versioni successive. Le password e Accedi con Google sono supportati a partire da Android 4.4. Per iniziare a utilizzare le passkey, segui questi passaggi:

1. Segui il codelab di Credential Manager per capire come implementare le passkey.
2. Esamina le linee guida per la progettazione dell'esperienza utente tramite passkey. Questo documento mostra i flussi consigliati per il tuo caso d'uso.
3. Studia Credential Manager seguendo la guida.
4. Pianifica l'implementazione di Credential Manager e delle passkey per la tua app. Pianifica l'aggiunta del supporto per Digital Asset Links.

Per maggiori dettagli su come creare, registrare e autenticare le passkey, consulta la nostra documentazione per gli sviluppatori.

Reimpostazione dell'account protetto

Un malintenzionato non autorizzato con accesso a un dispositivo sbloccato (ad esempio quando viene rubato uno smartphone) tenterà di accedere ad app sensibili, in particolare app bancarie o di contanti. Se l'app implementa la verifica biometrica, l'aggressore proverà a reimpostare l'account per accedervi. È essenziale che il flusso di reimpostazione dell'account non si basi esclusivamente su informazioni facilmente accessibili sul dispositivo, come link di reimpostazione OTP via email o SMS.

Di seguito sono riportate le best practice comuni che puoi incorporare nel flusso di ripristino della tua app:

• Riconoscimento facciale, oltre all'OTP
• Domande di sicurezza
• Fattore di conoscenza (ad esempio il cognome da nubile della madre, la città di nascita o la canzone preferita)
• Verifica dell'identità

API SMS Retriever

L'API SMS Retriever ti consente di eseguire automaticamente la verifica utente basata su SMS nella tua app per Android. In questo modo, l'utente non dovrà digitare manualmente i codici di verifica. Inoltre, questa API non chiede all'utente autorizzazioni app aggiuntive e potenzialmente pericolose come RECEIVE_SMS o READ_SMS. Tuttavia, gli SMS non devono essere utilizzati come unica verifica dell'utente per proteggere dall'accesso locale non autorizzato al dispositivo.

Come contribuisce a mitigare le frodi

Alcuni utenti utilizzano i codici SMS come unico fattore di autenticazione, il che fornisce un facile punto di accesso per le frodi.

L'API SMS Retriever consente all'app di recuperare direttamente il codice SMS senza interazione dell'utente e può fornire un livello di protezione dalle frodi.

Implementazione

L'implementazione dell'API SMS Retriever è composta da due parti: Android e server.

Android: (guida)

1. Ottieni il numero di telefono dell'utente.
2. Avvia il client di recupero SMS.
3. Invia il numero di telefono al tuo server.
4. Ricevere messaggi di verifica.
5. Invia l'OTP al tuo server.

Server: (guida)

1. Crea un messaggio di verifica.
2. Invia il messaggio di verifica via SMS.
3. Verifica l'OTP quando viene restituito.

Best practice

Una volta integrata l'app e verificato il numero di telefono dell'utente con l'API SMS Retriever, viene tentato il recupero dell'OTP. Se l'operazione va a buon fine, è un segnale forte che l'SMS è stato ricevuto automaticamente sul dispositivo. Se non va a buon fine e l'utente deve digitare manualmente l'OTP, potrebbe essere un segnale di avvertimento che l'utente potrebbe essere vittima di frode.

Gli SMS non devono essere utilizzati come unico meccanismo di verifica dell'utente, in quanto lasciano spazio ad attacchi locali, ad esempio un malintenzionato che ruba un dispositivo sbloccato, o ad attacchi di clonazione della SIM. È consigliabile utilizzare la biometria quando possibile. Sui dispositivi in cui i sensori biometrici non sono disponibili, l'autenticazione dell'utente deve basarsi su almeno un fattore che non sia facilmente ottenibile dal dispositivo corrente.

Nota: questa API non protegge da tutti i vettori di minaccia, come la clonazione della SIM.

Scopri di più

Per ulteriori informazioni sulle best practice, consulta le seguenti risorse:

• La nostra documentazione di Android sulla sicurezza
• Documentazione dell'API Play Integrity
• Modifiche di Android 15
• Best practice per la prevenzione delle chiamate fraudolente di Monzo Bank