Autenticazione sicura degli utenti

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

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

Finestra di dialogo Autenticazione biometrica

La libreria biometrica offre una serie 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 in modo da ricorrere all'LSKF, che presenta noti rischi di spallacci. Per le app sensibili, consigliamo di non far passare i dati biometrici al PIN e, dopo aver terminato i nuovi tentativi biometrici, gli utenti possono attendere o eseguire nuovamente l'accesso con la password o reimpostare gli account. La reimpostazione dell'account deve richiedere fattori non facilmente accessibili sul dispositivo (best practice di seguito).

In che modo questo contribuisce a mitigare le attività fraudolente e i furti di telefono

Un caso d'uso particolare che può essere utile per prevenire le attività fraudolente è 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 di destinazione a effettuare la transazione. Questa best practice protegge contro un utente malintenzionato che ruba un dispositivo, indipendentemente dal fatto che l'utente malintenzionato conosca o meno la LSKF, poiché dovrà verificare 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 frammento che contiene la logica con 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 azione esplicita dell'utente. Per evitare attività fraudolente, 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 nella UX, ma a causa della natura delle informazioni gestite in una transazione bancaria e del fatto che l'autenticazione biometrica è più fluida rispetto ad altri metodi di autenticazione, riteniamo che sia necessario aggiungere questo livello di navigazione.

Scopri di più sull'autenticazione biometrica.

Passkey

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

Le passkey possono soddisfare i requisiti di autenticazione a più fattori in un solo passaggio, sostituendo sia una password che i codici OTP per offrire una protezione solida contro gli attacchi di phishing ed evitare le difficoltà dell'esperienza utente dovute alle password uniche basate su app o SMS. Poiché le passkey sono standardizzate, una singola implementazione consente un'esperienza senza password su tutti i dispositivi, browser e sistemi operativi degli utenti.

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

In che modo questo contribuisce a mitigare le attività fraudolente

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

Il componente principale di una passkey è una chiave privata di crittografia. In genere, questa chiave privata si trova esclusivamente sui tuoi dispositivi, ad esempio laptop o cellulari, e viene sincronizzata tra i fornitori di credenziali (noti anche come gestori delle password), come Gestore delle password di Google. Quando viene creata una passkey, solo la chiave pubblica corrispondente viene salvata dal servizio online. Durante l'accesso, il servizio utilizza la chiave privata per firmare una richiesta dalla chiave pubblica. Può avere origine solo da uno dei tuoi dispositivi. Inoltre, affinché ciò avvenga, devi sbloccare il dispositivo o l'archivio di credenziali, che impedisce gli accessi non autorizzati (ad esempio, da uno smartphone rubato).

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

In caso di furto dello smartphone, le passkey ti proteggono perché i ladri non possono rubare le tue password per usarle su altri dispositivi. Le passkey sono specifiche per il tuo dispositivo. Se utilizzi Gestore delle password di Google e ti viene rubato il telefono, puoi accedere al tuo Account Google da un altro dispositivo (ad esempio un computer) e disconnetterti da remoto dal telefono rubato. Di conseguenza, Gestore delle password di Google, incluse le passkey salvate, sul telefono rubato, è inutilizzabile.

Nel caso peggiore, se il dispositivo rubato non viene recuperato, le passkey vengono sincronizzate di nuovo con il 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 nel 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 sul Gestore delle credenziali per acquisire una prima conoscenza su come implementare le passkey.
2. Consulta le linee guida per la progettazione dell'esperienza utente relative alle passkey. Questo documento mostra quali flussi sono consigliati per il tuo caso d'uso.
3. Segui la guida per imparare a utilizzare Gestore delle credenziali.
4. Pianifica l'implementazione di Gestore delle credenziali e delle passkey per la tua app. Pianifica l'aggiunta del supporto per Digital Asset Links.

Consulta la nostra documentazione per gli sviluppatori per ulteriori dettagli su come creare, registrare e eseguire l'autenticazione con le passkey.

Reimpostazione account sicuro

Un utente malintenzionato non autorizzato con accesso a un dispositivo sbloccato (ad esempio quando viene rubato un telefono) proverà ad accedere ad app sensibili, in particolare ad app di online banking o di contanti. Se l'app implementa la verifica biometrica, l'utente malintenzionato tenterà di reimpostare l'account per accedere. Per il flusso di reimpostazione dell'account è essenziale non basarsi solo su informazioni facilmente accessibili sul dispositivo, ad esempio link per la reimpostazione della password OTP via email o SMS.

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

• Riconoscimento facciale oltre a OTP
• Domande di sicurezza
• Fattore di conoscenza (come il cognome da nubile di una madre, la sua città di nascita o la sua 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, all'utente non sarà necessario digitare manualmente i codici di verifica. Inoltre, questa API non richiede all'utente autorizzazioni aggiuntive per app potenzialmente pericolose, come RECEIVE_SMS o READ_SMS. Tuttavia, gli SMS non devono essere usati come unica verifica dell'utente come protezione da accessi locali non autorizzati al dispositivo.

In che modo questo contribuisce a mitigare le attività fraudolente

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

L'API SMS Retriever consente all'app di recuperare direttamente il codice SMS senza interazione dell'utente e può fornire un livello di protezione contro le attività fraudolente.

Implementazione

L'implementazione dell'API SMS Retriever prevede due parti: Android e Server.

Android: (guida)

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

Server: (guida)

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

best practice

Dopo l'integrazione dell'app e la verifica del numero di telefono dell'utente con l'API SMS Retriever, l'app tenta di recuperare l'OTP. Se l'SMS va a buon fine, significa che l'SMS è stato ricevuto automaticamente sul dispositivo. Se l'operazione non viene eseguita correttamente e l'utente deve digitare manualmente la OTP, potrebbe essere un segnale di avviso che l'utente potrebbe essere vittima di una frode.

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

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

Scopri di più

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

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