implications de sécurité de stockage d'un mot de passe dans Settings.bundle et obtenir avec CFPreferencesCopyAppValue

Question

Toutes mes excuses pour l'évidence apparente de cette question, mais pour une raison quelconque, je ne l'ai pas été en mesure de trouver une réponse définitive dans la documentation d'Apple où et comment les informations mot de passe Settings.bundle est stocké. Ma question: si je dois stocker des informations d'identification pour une application, et j'utilise un Settings.bundle pour que le mot de passe est entré dans un champ texte de PSTextFieldSpecifier dans la zone Paramètres d'Apple avec isSecure = YES, puis-je accéder à la valeur de mon application à l'aide CFPreferencesCopyAppValue, écrit jamais vers NSUserDefaults et ne l'envoyer sur le réseau en toute sécurité, est-il sécurisé que la méthode de stockage et de récupération par rapport à stocker et récupérer le mot de passe en utilisant le trousseau dans mes propres paramètres de l'application? Merci pour vos commentaires.

Answer 1

CFPreferencesCopyAppValue est juste la façon d'accéder à la Fondation de base les mêmes informations que vous obtenez lorsque vous utilisez NSUserDefaults. En termes de sécurité, les caractéristiques sont exactement les mêmes. À savoir, ce n'est pas crypté. Il est sûr que dans le sens où il est obscurci. La réponse « correcte » est d'utiliser le trousseau.

Le compteur à ce que de nombreuses applications utilisent pour stocker les mots de passe NSUserDefaults. On pourrait dire que si les contrôles de mot de passe l'accès à l'information de toute valeur, alors il ne vaut pas l'effort d'essayer d'utiliser le trousseau. Ce qui me amène au deuxième argument en faveur de l'utilisation d'un champ sécurisé dans l'application Paramètres:. L'API trousseau est hideux et, dans mon expérience au moins, l'écriture de code sans erreur est délicate

Answer 2

Ne pas enregistrer le mot de passe d'un utilisateur dans le faisceau de paramètres.
Il est pas sûr.

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 le mot de passe d'origine. La bonne façon de traiter les mots de passe dans iOS est soit

• Utilisez le trousseau, comme d'autres l'ont mentionné
• 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

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:

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

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

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

Voici le code pour générer le sel et le hachage avant uniquement:

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

Code pour cet exemple a été trouvé ici: http://blog.securemacprogramming.com/2011/04/storing-and-testing-credentials-cocoa-touch-edition/

Answer 3

Keychain sur l'iPhone va être le plus sûr, à moins que vous utilisez le cryptage personnalisé, ce qui est très difficile à faire (et à l'exportation). NSUserDefaults n'est pas considéré comme sûr.