Autenticación de usuarios segura

Para proteger tu sistema de autenticación en Android, te recomendamos que no tengas un basado en contraseñas, en especial para cuentas sensibles, como las de banco y cuentas de correo electrónico. Recuerde que es posible que algunas aplicaciones que instalen los usuarios no tengan la las mejores intenciones y puede intentar suplantar la identidad de tus usuarios.

Tampoco des por sentado que solo los usuarios autorizados usarán el dispositivo. Robo de teléfono es un problema común, y los atacantes apuntan a dispositivos desbloqueados para beneficiarse directamente datos de usuarios o apps financieras. Sugerimos que todas las apps sensibles implementen un tiempo de espera de autenticación razonable (¿15 minutos?) con la verificación biométrica y requieren autenticación adicional antes de acciones sensibles, como dinero de datos.

Diálogo de autenticación biométrica

La biblioteca de datos biométricos ofrece un conjunto de funciones para mostrar un mensaje que solicita autenticación biométrica, como el reconocimiento facial o de huella dactilar. Sin embargo, los mensajes biométricos pueden configurarse para recurrir al LSKF, que tiene riesgos conocidos de navegación de hombros. En el caso de las apps sensibles, te recomendamos sin datos biométricos recurrir al PIN y, después de agotar los reintentos biométricos, Los usuarios pueden esperar, volver a acceder con una contraseña o restablecer cuentas. Restablecimiento de la cuenta requieren factores a los que no se pueda acceder fácilmente en el dispositivo (práctica recomendada a continuación).

Cómo ayuda a mitigar el fraude y el robo de llamadas telefónicas

Un caso de uso particular que puede ser útil para evitar fraudes es solicitar autenticación biométrica dentro de tu app antes de una transacción. Cuando los usuarios quieres realizar una transacción financiera, se muestra el diálogo biométrico para verificar que sea el usuario previsto quien realiza la transacción. Esta una práctica recomendada es evitar que un atacante robe un dispositivo sin importar el atacante conozca o no el LSKF, ya que deberá sondear que se propietario del dispositivo.

Para obtener niveles adicionales de seguridad, recomendamos que los desarrolladores de apps soliciten la clase 3 Autenticación biométrica y uso de CryptoObject para operaciones bancarias y transacciones financieras.

Implementación

  1. Asegúrate de incluir la biblioteca androidx.biometric.
  2. Incluye el diálogo de acceso biométrico en la actividad o el fragmento que contiene la lógica con la que quieres que se autenticó el usuario.

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

Prácticas recomendadas

Te recomendamos que comiences con el codelab para obtener más información sobre los datos biométricos.

Según tus casos de uso, puedes implementar el diálogo con o sin acción explícita del usuario. Para evitar fraudes, te recomendamos que agregues el dato con una acción explícita del usuario para cada transacción. Tenemos entendido que agregar autenticación puede introducir fricción en la UX, pero debido a la naturaleza de la información que se maneja en una transacción bancaria y que la autenticación es más fluida que la de otros métodos, creemos que es necesario para agregar este nivel de navegación.

Obtén más información sobre la autenticación biométrica.

Llaves de acceso

Las llaves de acceso son una alternativa más segura y sencilla a las contraseñas. Uso de llaves de acceso criptografía de clave pública para permitir que los usuarios accedan a apps y sitios web usando el mecanismo de bloqueo de pantalla del dispositivo, como una huella dactilar o el rostro el reconocimiento de imágenes. Esto evita que el usuario tenga que recordar y administrar contraseñas y brinda una seguridad mucho mejor.

Las llaves de acceso pueden cumplir con los requisitos de autenticación de varios factores en un solo paso, reemplazando contraseñas y códigos OTP para brindar protección sólida ataques de suplantación de identidad (phishing) y evitan que el usuario experimente la molestia de enviar solo SMS o apps contraseñas. Como las llaves de acceso están estandarizadas, una sola implementación permite una experiencia sin contraseña en todas las cuentas dispositivos, navegadores y de los sistemas operativos.

En Android, las llaves de acceso son compatibles con el Administrador de credenciales de Jetpack. que unifica los principales métodos de autenticación, como las llaves de acceso, contraseñas y accesos federados (como Acceder con Google).

Cómo ayuda esto a mitigar el fraude

Las llaves de acceso te protegen de los ataques de phishing porque solo funcionan en tu apps y sitios web registrados.

El componente principal de una llave de acceso es una clave privada criptográfica. Por lo general, este clave privada reside únicamente en sus dispositivos, como computadoras portátiles o teléfonos celulares, y se sincroniza entre ellos mediante proveedores de credenciales (también conocidos como administradores), como el Administrador de contraseñas de Google. Solo se agrega la clave pública correspondiente que guarda el servicio en línea cuando se crea una llave de acceso. Durante el acceso, el servicio usa la clave privada para firmar un desafío a partir de la clave pública. Esta acción solo puede se originan en uno de tus dispositivos. Además, para que esto ocurra, debes Desbloquear el dispositivo o el almacén de credenciales, lo que impide los accesos no autorizados. (por ejemplo, de un teléfono robado).

Para evitar accesos no autorizados en caso de robo y desbloqueo, llaves de acceso deben combinarse con una ventana de tiempo de espera de autenticación razonable. Los el atacante que roba un dispositivo no debería poder usar una aplicación porque el usuario anterior había accedido. En cambio, las credenciales deben caducan a intervalos regulares (por ejemplo, cada 15 minutos), y se debe para verificar su identidad mediante la reautenticación con bloqueo de pantalla.

Si te roban el teléfono, las llaves de acceso te protegen porque los ladrones no pueden robar tus datos contraseñas para usar en otros dispositivos, las llaves de acceso son específicas del dispositivo. Si usas El Administrador de contraseñas de Google y tu teléfono te roban, puedes acceder a tu desde otro dispositivo (como una computadora) y salir de forma remota de teléfono robado. Esto hace que el Administrador de contraseñas de Google en el teléfono robado inutilizable, incluidas las llaves de acceso guardadas.

En el peor de los casos, si no se recupera el dispositivo robado, las llaves de acceso se que el proveedor de credenciales creó y sincronizó con el dispositivo nuevo la llave de acceso. Por ejemplo, el usuario puede haber elegido el Administrador de contraseñas de Google para crea la llave de acceso y podrá acceder a ella en un dispositivo nuevo volver a su Cuenta de Google y proporcionar el bloqueo de pantalla del anterior dispositivo.

Obtén más información en el Seguridad de las llaves de acceso en el artículo del Administrador de contraseñas de Google

Implementación

Las llaves de acceso son compatibles con dispositivos que ejecutan Android 9 (nivel de API 28) o versiones posteriores. Las contraseñas y Acceder con Google son compatibles a partir de Android 4.4. Para comienza a usar llaves de acceso, sigue estos pasos:

  1. Sigue el codelab del Administrador de credenciales para comprender inicialmente cómo implementar las llaves de acceso.
  2. Revisa los lineamientos de diseño de la experiencia del usuario de las llaves de acceso. En este documento, se muestra qué flujos se recomiendan para tu caso de uso.
  3. Estudia el Administrador de credenciales siguiendo la guía.
  4. Planifica la implementación del Administrador de credenciales y llaves de acceso para tu app. Planifica cómo agregar compatibilidad con Vínculos de recursos digitales.

Consulta nuestra documentación para desarrolladores si deseas obtener más detalles sobre cómo crear, registrar y se autentican con llaves de acceso.

Restablecimiento seguro de la cuenta

Un atacante no autorizado con acceso a un dispositivo desbloqueado (como cuando un teléfono si se roba) intentará acceder a aplicaciones sensibles, en especial a aplicaciones bancarias o de dinero en efectivo. Si la app implementa la verificación biométrica, el atacante intentará restablecerla a la cuenta para ingresar. Es esencial que el flujo de restablecimiento de cuentas no solo dependa en información a la que se pueda acceder fácilmente en el dispositivo, como correos electrónicos u OTP por SMS restablecer vínculos.

A continuación, se incluyen algunas prácticas recomendadas comunes que puedes incorporar al proceso de restablecimiento. flujo:

  • El reconocimiento facial, además de la OTP
  • Preguntas de seguridad
  • Factor de conocimiento (como el apellido de soltera de la madre, la ciudad de nacimiento o el favorito canción)
  • Verificación de ID

API de SMS Retriever

La API de SMS Retriever te permite realizar una verificación de usuario basada en SMS en tu app para Android automáticamente. De esa manera, no será necesario que el usuario escribir manualmente los códigos de verificación Además, esta API no le hace preguntas al usuario para permisos adicionales de apps potencialmente peligrosos, como RECEIVE_SMS o READ_SMS Sin embargo, el SMS no debe usarse como la única verificación del usuario para proteger el dispositivo contra accesos locales no autorizados.

Cómo ayuda esto a mitigar el fraude

Algunos usuarios utilizan códigos SMS como único factor de autenticación que proporciona un punto de entrada fácil para fraudes.

La API de SMS Retriever permite que la app recupere directamente el código SMS sin la interacción con los usuarios y pueden brindar un nivel de protección contra el fraude.

Implementación

La implementación de la API de SMS Retriever tiene dos partes: Android y Server.

Android: (guía)

  1. Obtén el número de teléfono del usuario.
  2. Inicia el cliente de SMS retriever.
  3. Envía el número de teléfono a tu servidor.
  4. Recibir mensajes de verificación
  5. Envía la OTP a tu servidor.

Servidor: (guía).

  1. Crea un mensaje de verificación.
  2. Envía el mensaje de verificación por SMS.
  3. Verifica la OTP cuando se devuelva.

Prácticas recomendadas

Una vez que se integra la app y se verifica el número de teléfono del usuario con la API de SMS Retriever, intenta obtener la OTP. Si tiene éxito, es una estrategia sólida indicar que el SMS se recibió automáticamente en el dispositivo. Si no correctamente y el usuario debe escribir manualmente la OTP, puede ser una señal de advertencia de que el usuario pueda estar sufriendo fraude.

El SMS no debe usarse como el único mecanismo de verificación del usuario, ya que deja espacio. a ataques locales, como un atacante que roba un dispositivo desbloqueado o SIM de la clonación de datos. Se recomienda usar datos biométricos siempre que sea posible. Activada dispositivos sin sensores biométricos, la autenticación del usuario dependen de al menos un factor que no se obtiene fácilmente del dispositivo actual.

Más información

Para obtener más información sobre las prácticas recomendadas, consulta los siguientes recursos: