10
votes

Implications de sécurité de stocker un mot de passe dans les paramètres.bundle et à obtenir avec cfpreferencesCopyAppValue

Toutes mes excuses pour la évidence semblant évidente de cette question, mais pour une raison quelconque, je n'ai pas été en mesure de trouver une réponse définitive dans la documentation Apple sur l'endroit où et la manière dont les informations de mot de passe des paramètres sont stockées. Ma question: Si je dois stocker des informations d'identification pour une application, et j'utilise un paramètre.Bundle de sorte que le mot de passe soit entré dans un fichier de texte PstextFieldSpecifiant dans la zone Paramètres d'Apple avec Issecure = Oui, puis j'accède à la valeur de mon application à l'aide de mon application. CFPreFerencesCopyAppValue, n'écrivez jamais à Nsuserdefaults et ne l'envoyez-vous que sur le réseau, à quel point la sécurité est la méthode de stockage et de récupération par rapport au stockage et à la récupération du mot de passe à l'aide du porte-clés dans mes propres paramètres de l'application? Merci pour votre contribution.


3 commentaires

Envisagez de stocker le hachage au lieu du mot de passe. Voir ma réponse ci-dessous.


Merci pour la bonne suggestion - comme je l'ai mentionné à l'époque que j'ai posé quelques années il y a quelques années, je suis bloqué avec l'utilisation du porte-clés.


Ouais. C'est une bonne option et Apple l'a certainement amélioré depuis que vous avez demandé d'abord.


3 Réponses :


8
votes

cfpreferencesCopyAppValue est juste la méthode de base d'accéder aux mêmes informations que vous obtenez lors de l'utilisation de nsuserdefault . En termes de sécurité, les caractéristiques sont exactement les mêmes. C'est-à-dire que ce n'est pas crypté. Il est sécurisé que dans le sens où il est obscurci. La réponse "correcte" consiste à utiliser le porte-clés.

Le compteur à qui est que de nombreuses applications utilisent nsuserdefault pour stocker des mots de passe. Vous pouvez affirmer que si le mot de passe ne contrôle l'accès à des informations de toute valeur, il ne vaut pas l'effort d'utiliser le porte-clés. Ce qui m'amène au deuxième argument en faveur d'utiliser un champ sécurisé dans l'application Paramètres: l'API Keychain est hideuse et, au moins, dans mon expérience, le code sans erreur est délicat.


3 commentaires

Bon à savoir, merci. Je vais coller avec le porte-clés - ce n'était pas clair pour moi que les informations des paramètres se retrouvaient au même endroit que Nsuserdefault.


Vous êtes peut-être intéressé à utiliser SFHFeyChainutils: Github.com/ldandersen/scifihifidididiphone/ Arbre / ... . Je l'utilise pour stocker des mots de passe et simplifie vraiment l'utilisation du porte-clés.


J'ai constaté que le code d'échantillon Apple qui a une implémentation d'un wrapper Keychain pour les services Keychain est assez facile à suivre (puis utilisez ensuite le wrapper pour votre propre clé de clés d'application) si vous supprimez le code de présentation du contrôleur d'affichage. , que je pense, c'est où la plus grande partie de la confusion entre dans cet exemple.



3
votes

Keychain sur l'iPhone sera le plus sécurisé, à moins que vous n'ayez en cryptage personnalisé, ce qui est très difficile à faire (et à l'exportation). Nsuserdefaults n'est pas considéré comme sécurisé.


0 commentaires

8
votes

Ne pas enregistrer le mot de passe d'un utilisateur dans les paramètres bundle.
Il est pas sécurisé.

Rappelez-vous, vous n'avez pas besoin de savoir ce que le mot de passe d'origine est, vous devez savoir si le mot de passe que l'utilisateur entre correspond em> le mot de passe d'origine. La bonne façon de traiter les mots de passe dans iOS est soit p>

  • Utilisez le trousseau, comme d'autres l'ont mentionné li>
  • Générer une fonction de hachage cryptographique à sens unique en utilisant SHA-512 ou un chiffrement et de stocker le hachage et le sel dans NSUserDefaults code> li> Ul>

    ces options, chiffrer le mot de passe et le stockage du hachage + sel est de loin le plus facile. Voici ce que vous faites pour stocker le mot de passe: p>

    1. Saisir le mot de passe de l'utilisateur li>
    2. Créez une valeur de sel aléatoire li>
    3. Créer un hachage avant uniquement en utilisant SHA-512 et la valeur de sel aléatoire li>
    4. Mémorisez le hachage et la valeur du sel dans NSUserDefaults code> -. Ces valeurs ne peuvent pas être utilisées par les pirates pour déterminer le mot de passe d'origine, il n'y a donc pas besoin de les stocker dans un endroit sûr Ol>

      Maintenant, lorsque l'utilisateur entre son mot de passe et vous devez vérifier si elle est correcte, voici ce que vous faites: p>

      1. Saisir le mot de passe de l'utilisateur li>
      2. Saisissez la valeur de sel de hachage + précédemment enregistré à partir de NSUserDefaults code> li>
      3. Créer un hachage avant uniquement en utilisant le même sens unique fonction de hachage que vous avez utilisé pour chiffrer le mot de passe d'origine - en lui transmettant le mot de passe de tentative et la valeur de sel de NSUserDefaults code> li>
      4. Comparer le hachage avec celui qui a été stocké dans NSUserDefaults code>. Si elles sont les mêmes, l'utilisateur est entré dans le mot de passe correct. Li> Ol>

        Voici le code pour générer le sel et l'avant uniquement hachage: p>

        NSString *FZARandomSalt(void) {
            uint8_t bytes[16] = {0};
            int status = SecRandomCopyBytes(kSecRandomDefault, 16, bytes);
            if (status == -1) {
                NSLog(@"Error using randomization services: %s", strerror(errno));
                return nil;
            }
            NSString *salt = [NSString stringWithFormat: @"%2x%2x%2x%2x%2x%2x%2x%2x%2x%2x%2x%2x%2x%2x%2x%2x",
                              bytes[0],  bytes[1],  bytes[2],  bytes[3],
                              bytes[4],  bytes[5],  bytes[6],  bytes[7],
                              bytes[8],  bytes[9],  bytes[10], bytes[11],
                              bytes[12], bytes[13], bytes[14], bytes[15]];
            return salt;
        }
        
        NSData *FZAHashPassword(NSString *password, NSString *salt) {
            NSCParameterAssert([salt length] >= 32);
            uint8_t hashBuffer[64] = {0};
            NSString *saltedPassword = [[salt substringToIndex: 32] stringByAppendingString: password];
            const char *passwordBytes = [saltedPassword cStringUsingEncoding: NSUTF8StringEncoding];
            NSUInteger length = [saltedPassword lengthOfBytesUsingEncoding: NSUTF8StringEncoding];
            CC_SHA512(passwordBytes, length, hashBuffer);
            for (NSInteger i = 0; i < 4999; i++) {
                CC_SHA512(hashBuffer, 64, hashBuffer);
            }
            return [NSData dataWithBytes: hashBuffer length: 64];
        }
        


0 commentaires