ios - reinicia - touch id no reconoce mi huella

SecItemCopyMatching para Touch ID sin código de acceso alternativo

Question

Estoy utilizando SecItemCopyMatching para buscar un elemento de llavero protegido por Touch ID.

Sin embargo, si falla el desbloqueo de Touch ID (o el usuario selecciona "Introducir contraseña"), quiero presentar mi propia IU de entrada de PIN.

No quiero que al usuario se le presente la IU de entrada de código de acceso del sistema en ningún momento.

El método de evaluatePolicy LAContext proporciona esto, pero no ofrece ninguna seguridad real de llavero, simplemente autenticación local.

Por lo tanto, no LAContext para lograr esto. ¿Es esto posible con SecItemCopyMatching ?

Answer 1

En iOS 8.3 y versiones posteriores, la opción de retroceso de código de acceso está oculta inicialmente, pero aún aparece si no se reconoce el primer dedo presentado.

Para iOS 9, se han agregado dos nuevas políticas que no se basan en el código de acceso. Estas políticas son kSecAccessControlTouchIDAny y kSecAccessControlTouchIDCurrentSet

Answer 2

Esto probablemente debería ser un comentario para bllakjakk, pero mi reputación no me permite hacerlo todavía.

Solo estoy agregando esta respuesta porque la pregunta fue específicamente sobre:

buscar un artículo de llavero protegido por Touch ID

La respuesta aceptada menciona un escenario donde no se almacenan credenciales en el dispositivo.

Para completar, quería mencionar que si su aplicación necesita autenticarse en alguna entidad externa y, por lo tanto, debe almacenar las credenciales en algún lugar, entonces la opción de cadena de claves es la que debe considerar a través de la Autenticación local.

El temor de que alguien pueda autenticarse por medio de la Cadena de claves si conoce el código de acceso del dispositivo (cuatro dígitos potencialmente débiles y demás) es un punto discutible porque nada impide que un usuario agregue su propia huella digital al dispositivo si poseen el código de acceso y luego se autentican a través de Key-Chain o Autenticación local sin tener que seleccionar el respaldo .

Por lo tanto, si utiliza la Autenticación local sobre la Cadena dominante porque considera que el mecanismo alternativo es más seguro, es posible que esté pasando por alto ese pequeño detalle y, por lo tanto, deje pasar la oportunidad de almacenar las credenciales en el enclave seguro.

Estamos a punto de implementar TouchID para una aplicación financiera y estamos optando por Key-Chain. El objetivo es educar a nuestros usuarios sobre la necesidad de contar con códigos de acceso de dispositivos fuertes en el momento en que intenten habilitar TouchID para nuestra aplicación.

Espero que esto te ayude a tomar una decisión.

Answer 3

No hay forma de deshabilitar el mecanismo de respaldo mediante el uso de código de acceso en la integración de Keychain TouchID. Use LocalAuthentication en su lugar (pero LocalAuthentication solo proporciona una IU de autenticación de TouchID aunque no está relacionada con el Keychain).

Answer 4

Puede intentar ocultar el botón Enter Password haciendo lo siguiente:

1) definir la función global

static bool new_isFallbackButtonVisible(id self, SEL _cmd)
{
return NO;
}

2) en su application:didFinishLaunchingWithOptions: reemplace el método LAContext clase LAContext con su nueva implementación llamando

class_replaceMethod(NSClassFromString(@"LAContext"), NSSelectorFromString(@"isFallbackButtonVisible"), (IMP)new_isFallbackButtonVisible, "v@:B");

Answer 5

Puede ocultar / personalizar la opción "Ingresar contraseña" configurando:

LAContext *context = [[LAContext alloc] init];
context.localizedFallbackTitle = @"";

y la opción desaparecerá, o:

LAContext *context = [[LAContext alloc] init];
context.localizedFallbackTitle = @"Disable TouchID";

para personalizar el texto de la opción. Si bien sé que esto no es exactamente lo que el OP estaba preguntando, sin duda está relacionado y podría "caer" en las mentes deficientes.

Answer 6

Tuvimos un dilema similar al trabajar en una de nuestras aplicaciones en producción. Nos dimos cuenta de que necesitamos el desbloqueo de identificación táctil, así como el mecanismo de repliegue personalizado (que requiere la API del servidor para desbloquear), que es más fuerte que la contraseña de desbloqueo de 4 dígitos.

Entonces, déjame tratar de explicar cómo lo logramos. Similarmente, se espera que Apple haga lo mismo para la compra de Appstore y la aplicación 1Password.

Fondo:

Dos mecanismos para integrar Touch ID:

1. Use Touch ID para acceder a las credenciales almacenadas en el llavero

   Problema:

   Si un dispositivo tiene Touch ID también, el método preferido es autenticarse con Touch ID y el código de acceso es el mecanismo de respaldo.

   No se permite ningún otro mecanismo alternativo y Apple no permite la personalización de la interfaz de usuario alternativa.

2. Use Touch ID para autenticarse con la aplicación directamente (llamada Autenticación local)

   Problema:

   No se concede permiso para almacenar secretos o recuperar secretos del Enclave Seguro

   Contrario al caso de acceso de llavero, Apple no permite la autenticación de código de acceso del dispositivo como respaldo. Cada aplicación necesita proporcionar su propio respaldo para manejar el caso de Touch ID fallido con interfaz de usuario personalizada.

Preocupación:

Acerca del almacenamiento de información confidencial en el llavero:

Estuvimos tentados de utilizar este enfoque, pero nos sorprendimos al darnos cuenta de que la única desventaja de no autenticarse con Touch ID es el código de acceso del dispositivo. Los usuarios de iOS suelen configurar un código de acceso de cuatro dígitos, que es menos seguro que las contraseñas personalizadas de los usuarios.

Ejemplos de estiramiento facial:

Apple usa su contraseña de cuenta de iCloud [mecanismo de respaldo personalizado] como mecanismo de respaldo para la compra en iTunes Store si el usuario no puede autenticarse con Touch ID.

La aplicación 1Password también tiene un enfoque similar.

Conclusión

En nuestra aplicación, nos autenticamos con Touch ID a través de LocalAuthentication, usamos nuestra ''aplicación específica de desbloqueo de PIN'' o la contraseña del cliente como mecanismo de respaldo.

No almacenamos la contraseña en el dispositivo, la falta de autenticación con Touch ID requiere una autenticación completa a través de la API de los servidores, si el dispositivo no tiene un PIN configurado dentro de la aplicación.

Código de muestra:

[self.laContext evaluatePolicy:LAPolicyDeviceOwnerAuthenticationWithBiometrics
localizedReason:reason
reply:^(BOOL success, NSError *error) {
if (success)
dispatch_async(dispatch_get_main_queue(), ^{ successBlock(); });
else
dispatch_async(dispatch_get_main_queue(), ^{ fallbackBlock(error); });
self.laContext = nil;
}
];