web-dev-qa-db-fra.com

Détecter par programme si le code d'accès iOS est activé ou non

Plutôt que de créer un mot de passe directement dans mon application et d'obliger potentiellement l'utilisateur à saisir deux fois un code (une fois pour l'appareil et une autre pour mon application); Je pensais que je pourrais me dépasser et faire quelque chose comme:

if (device has passcode)
    continue into my app
else
    make user enter my app passcode

Je ne veux pas définir le mot de passe de l'appareil, je ne veux pas forcer un verrouillage d'écran, ne pas chiffrer quoi que ce soit - tout ce que je veux vraiment, c'est une API juste pour détecter si un mot de passe d'appareil est en vigueur. Quelque chose comme:

BOOL notReally = [UIDevice isUserSlightlyMoreSecureBecauseTheySetDeviceLockOn];

ou peut-être si j'ai de la chance:

BOOL isPasscodeEnabled = [UIDevice isPasscodeEnabled];
BOOL isSimplePasscode = [UIDevice isSimplePasscode];
NSInteger minutes = [UIDevice requirePasscodeAfter];

Je suppose que ce n'est pas basé sur cette question (mais il y a quelques années) " vérifier par programme le mot de passe de l'iPhone dans le groupe de paramètres " ou cela pourrait être la réponse; " Lock Unlock events iphone " ce qui n'est pas exactement ce que je veux mais pourrait fonctionner "après coup".

iosscreen-lockparental-control
22
Eric

Mettre à jour

Depuis iOS 9, vous pouvez y parvenir en utilisant le LocalAuthentication.framework. Si vous ciblez iOS 9+, lisez les commentaires ici ou regardez cette réponse .

Si vous devez toujours cibler iOS 8, continuez à lire :)

À partir d'iOS8, c'est possible!
J'ai mis en place une catégorie simple pour vérifier facilement l'état: https://github.com/liamnichols/UIDevice-PasscodeStatus

Comment ça fonctionne

Cette catégorie fonctionne en utilisant les nouvelles fonctionnalités accessControl ajoutées au Security.Framework dans iOS 8. Elle tente d'ajouter un élément au trousseau en utilisant le niveau de protection kSecAttrAccessibleWhenPasscodeSetThisDeviceOnly.

La documentation indique ce qui suit:

Les données de l'article ne sont accessibles que lorsque l'appareil est déverrouillé. Cette classe n'est disponible que si un code d'accès est défini sur l'appareil. Ceci est recommandé pour les éléments qui ne doivent être accessibles que lorsque l'application est au premier plan. Les éléments avec cet attribut ne migreront jamais vers un nouveau périphérique, donc après la restauration d'une sauvegarde sur un nouveau périphérique, ces éléments seront manquants. Aucun élément ne peut être stocké dans cette classe sur des appareils sans code d'accès. La désactivation du code d'accès de l'appareil entraînera la suppression de tous les éléments de cette classe.

Pour cette raison, une erreur est renvoyée lorsque vous essayez d'ajouter ou de lire un élément dans le trousseau avec ce niveau d'accèsControl. Si nous voyons cette erreur, le passcodeStatus retourne comme LNPasscodeStatusDisabled. Si nous pouvons lire ou écrire avec succès sur le trousseau avec ce niveau de accessControl, alors nous retournons LNPasscodeStatusEnabled.

Si le périphérique n'est pas pris en charge ou si une erreur sans rapport avec le trousseau est renvoyée, nous renvoyons LNPasscodeStatusUnknown.

27
liamnichols

Pour iOS 9+, vous pouvez le détecter à l'aide de la nouvelle classe LocalAuthentication, et cela fonctionne sur Simulator ainsi que sur les appareils:

import LocalAuthentication

private func devicePasscodeSet() -> Bool {
    //checks to see if devices (not apps) passcode has been set
    return LAContext().canEvaluatePolicy(.DeviceOwnerAuthentication, error: nil)
  }
33
sschale

Je ne connais aucun moyen d'obtenir directement ces informations, mais je pense que vous pouvez probablement obtenir le résultat que vous recherchez en utilisant les effets secondaires de la prise en charge par Apple du chiffrement de disque. Voir Protection des données à l'aide du chiffrement sur disque pour plus de détails.

Cependant, c'est un hack plutôt qu'un comportement conçu, et il y a des cas d'angle dont il ne sera pas au courant. Je recommanderais de faire de cette fonctionnalité quelque chose qui est explicitement sous le contrôle de l'utilisateur plutôt que quelque chose que vous activez avec l'heuristique.

1
Jim