SecItemCopyMatching для Touch ID без возврата кода

Ответ 1

В iOS 8.3 и выше опция резервного кода паролей сначала скрыта, но все же появляется, если первый палец не распознан.

Для iOS 9 добавлены две новые политики, которые не возвращаются к паролю. Этими политиками являются kSecAccessControlTouchIDAny и kSecAccessControlTouchIDCurrentSet

Ответ 2

Вероятно, это комментарий к bllakjakk, но моя репутация пока не позволяет мне это делать.

Я только добавляю этот ответ, потому что в вопросе конкретно спрашивали:

извлекает элемент keychain, защищенный Touch ID

В принятом ответе упоминается сценарий, в котором учетные данные не хранятся на устройстве.

Для полноты я хотел упомянуть, что если ваше приложение должно пройти аутентификацию для какого-либо внешнего объекта, и поэтому вам нужно где-то хранить учетные данные, тогда опция Key-Chain - это вопрос, который следует учитывать при локальной аутентификации.

Страх перед тем, что кто-то может пройти аутентификацию через резерв для Key-Chain, если они знают прокси-код устройства (потенциально слабый четырехзначный и т.д.), является спорным вопросом, потому что ничего не позволяет пользователю добавлять свои собственный отпечаток пальца на устройстве, если они обладают паровым кодом, а затем аутентифицируются через Key-Chain или Local Authentication без необходимости выбирать резервный.

Итак, если вы используете локальную проверку подлинности по цепочке ключей, потому что чувствуете, что резервный механизм более безопасен, вы можете не заметить эту мелкую деталь и, следовательно, отказаться от возможности хранить учетные данные в защищенном анклаве.

Мы собираемся внедрить TouchID для финансового приложения и выбираем Key-Chain. Цель состоит в том, чтобы обучить наших пользователей необходимости использования прочных кодов устройств в то время, когда они пытаются включить TouchID для нашего приложения.

Надеюсь, это поможет вам принять решение.

Ответ 3

У нас была аналогичная дилемма, работая над одним из наших in-production приложений. Мы поняли, что нам нужно разблокировать идентификатор касания, а также настраиваемый механизм резервного копирования (для которого требуется серверный API для разблокировки), который сильнее, чем четырехзначный пароль разблокировки.

Итак, позвольте мне попытаться объяснить, как мы это достигаем. Подобное, как ожидается, будет сделано Apple для покупки Appstore и 1Password.

Фон:

Два механизма для интеграции Touch ID:

• Используйте Touch ID для доступа к учетным данным, хранящимся в цепочке ключей

  Вопрос:

  Если у устройства также есть сенсорный идентификатор, предпочтительным методом является аутентификация с помощью Touch ID, а код доступа - механизм резервного копирования.

  Никакой другой резервный механизм не разрешен, и Apple не позволяет настраивать резервный пользовательский интерфейс

• Использовать сенсорный идентификатор для аутентификации с помощью приложения (локальная аутентификация)

  Вопрос:

  Не предоставляется разрешение на хранение секретов в секреты безопасного захвата и их получение

  В отличие от случая доступа к keychain, Apple не разрешает аутентификацию пароля на устройстве в качестве резервной копии      Каждое приложение должно предоставить свой собственный резерв, чтобы обработать неудачный код Touch ID с пользовательским интерфейсом

Концерн:

О хранении конфиденциальной информации в цепочке ключей:

Мы искушались использовать этот подход, но были ошеломлены, осознав, что единственным откатом за невозможность аутентификации с помощью Touch ID является код доступа к устройству. Пользователи iOS обычно настраивают четырехзначный код доступа, который менее безопасен, чем пользовательские пароли пользователей.

Примеры подтяжки лица:

Apple использует ваш пароль учетной записи iCloud [пользовательский резервный механизм] в качестве резервного механизма для покупки магазина itunes, если пользователь не может выполнить аутентификацию с помощью Touch ID.

1Password-приложение также имеет схожий подход.

Заключение

В нашем приложении мы аутентифицируемся с помощью Touch ID с помощью LocalAuthentication, мы используем нашу "функцию разблокировки PIN-кода для конкретного приложения" или пароль клиента в качестве резервного механизма.

Мы не храним пароль на устройстве, неспособность аутентифицироваться с помощью Touch ID требует полной проверки подлинности через API серверов, если у устройства нет PIN-кода, настроенного в приложении.

Пример кода:

[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;
                         }
];

Ответ 4

Вы можете попытаться скрыть кнопку Enter Password, выполнив следующие действия:

1) определить глобальную функцию

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

2) в application:didFinishLaunchingWithOptions: замените isFallbackButtonVisible метод класса LAContext на новую реализацию, вызвав

class_replaceMethod(NSClassFromString(@"LAContext"), NSSelectorFromString(@"isFallbackButtonVisible"), (IMP)new_isFallbackButtonVisible, "[email protected]:B");

Ответ 5

Невозможно отключить механизм резервного копирования с использованием кода доступа в интеграции Keychain TouchID. Вместо этого используйте LocalAuthentication (Но LocalAuthentication просто предоставляет пользовательский интерфейс TouchID, хотя не связан с цепочкой ключей).

Ответ 6

Вы можете скрыть/настроить параметр "Ввести пароль", установив:

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

и опция исчезнет, ​​или:

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

чтобы настроить текст опции. Хотя я знаю, что это не совсем то, о чем спрашивал ОП, это, безусловно, связано и может "отбросить" на желающих умов.