Как безопасно хранить данные с помощью objective C? (Mac / Cocoa Dev)

Я пытаюсь создать пробную часть моего приложения cocoa. У меня есть все лицензии (включая ключи)и т. д.

но мне было интересно, как я могу хранить e.g первый раз, когда пользователь запустил программу в безопасном месте, где пользователь не может легко найти и/или отредактировать ее.

У меня была возня с NSUserDefaults standardUserDefaults, но пользователь может легко найти и отредактировать эти данные в Library > Preferences.

6 ответов


Я бы возражал против того, чтобы сделать его супер-безопасным. У нас когда-то была активация сервера, но полностью ушла от нее. Вот некоторые из причин:

  • даже самый "безопасный" метод хранения может быть сломан
  • даже для нишевого продукта трещина может быть разработана, не обойдется, независимо от того, насколько безопасен ваш метод
  • есть несколько, очень дорогих, очень безопасных методов. Все остальные были взломаны
  • это идет против честных и честных пользователей, что делает его более трудным для них, чтобы исправить вещи, вызывающие проблемы
  • если тут взломать программное обеспечение или обойти вашу безопасность, он, вероятно, также никогда не купил его
  • 80% пользователей даже не знают, что предпочтение файл
  • 95% пользователей не думают о возможности удалить его для того, чтобы продлить пробную
  • простой способ сброса пробных периодов массово облегчает вашу поддержку для пользователей, которых вы хотите дайте второе испытание по какой-либо причине
  • доверять пользователям-хорошая точка продажи
  • опытные пользователи, как правило, поворачиваются против программного обеспечения с слишком большой защитой

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


вы не можете использовать файл в файловой системе. Любой, кто будет искать скрипку/трещину, будет достаточно умен, чтобы знать, как отслеживать доступ к файлам через основные стандартные функции OSX. Таким образом, добавляемый файл отсутствует. Не только это, но и плохое поведение для создания файлов, которые вы не удаляете при удалении приложения. Люди не должны потреблять ресурсы после удаления пробного приложения.

Как отмечалось выше, возиться в вашем комплекте-тоже плохая идея. Это оставляет вас с тремя основными вариантами.

1) Не беспокойтесь об этом слишком много. Используйте базовую систему истечения срока действия, использующую стандартные расположения и методы. Вы все еще можете использовать шифрование в данных, которые вы храните, но знаете, что это тоже будет нарушено. Примите, что нарушение авторских прав будет происходить, если ваше приложение не является полностью непопулярным.

2) Используйте сетевой вызов и выполните проверку на сервере. Это потребует, чтобы приложение всегда было в состоянии добраться до вашей службы для запуска. Это не в общем, хорошая идея. Что если ваши серверы не работают? Что, если они отключены? Что, если между вами и ними возникнет сетевая проблема? Все эти сценарии обязательно произойдут. Когда они это сделают, вы, скорее всего, потеряете клиентов, если ваше приложение не требует подключения к вашим серверам уже для работы (например, Twitter или Facebook).

3) быть "плохим гражданином", возясь с пакетом приложений или оставляя сиротские файлы вокруг. Если вы сделаете это последнее, по крайней мере убедитесь, что они четко названы так, что они относятся к вашему приложению, очевидно.

в конечном итоге, главное помнить, что у вас нет безопасности на компьютере пользователя. Это их. Это означает, что у них есть физический доступ, который практически сводит на нет любые попытки помешать им копать. Вы также можете посмотреть на это так: чем более технически ориентирован ваш рынок, тем меньше вероятность того, что вы будете умнее всех нас, и ваша "безопасность" будет взломана. Если вы разрабатываете для нетехническая аудитория тогда вы можете понять, что в целом они не будут беспокоиться о его взломе или поиске.

вы можете потратить свои ресурсы на то, чтобы сделать приложение лучше или дать себе лучшее чувство о людях, не использующих его в течение пробного периода. Один из них может увеличить ваши продажи, а другой-нет.

[редактирование] Также я должен отметить, что одним из наиболее распространенных (если не самым распространенным) средств взлома этих вещей является изменение двоичного файла. Таким образом, нарушая подписание кода с помощью bundle mucking, вы фактически откроете себя этому методу, потому что вы нарушите одну из лучших защит, которые у вас есть. Большинство трещин включают двоичные файлы, изменяемые таким образом, что процедура, которая делает проверки всегда возвращает успешную аутентификацию.


Аллан Одгаард имеет довольно приличный рецензия о том, как использовать OpenSSL для создания/хранения лицензионных ключей для программного обеспечения Cocoa. Может, стоит почитать.


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

посмотреть в Общие Крипто дайджест библиотека.

Это защитит от почти всех случайных пользователей. Хотя хакеры могут, с достаточной мотивацией, найти способ обойти.


попробуйте сохранить файл, имя которого начинается с точки в какой-либо папке, а затем установить скрытый флаг файла.

хорошим местом для размещения скрытого файла будет неясно названный файл в базе папки пользователей ( ~ / ), там много неясных скрытых файлов, поэтому трудно понять, какой из них вы можете и не можете удалить. пример пути: ~/.xdarwinprofile или что-то столь же официальное звучание.

вот код, который должен работать, чтобы скрыть файл:

#include <assert.h>
#include <stdio.h>
#include <stddef.h>
#include <string.h>
#include <sys/attr.h>
#include <sys/errno.h>
#include <unistd.h>
#include <sys/vnode.h>

typedef struct attrlist attrlist_t;

struct FInfoAttrBuf {
    u_int32_t length;
    fsobj_type_t objType;

    union {
        char rawBytes[32];

        struct {
            FileInfo info;
            ExtendedFileInfo extInfo;
        } file;

        struct {
            FolderInfo info;
            ExtendedFolderInfo extInfo;
        } folder;
    } finderInfo;
};
typedef struct FInfoAttrBuf FInfoAttrBuf;


- (int)SetFileInvisibility:(NSString *)filePath state:(BOOL)isInvisible) {
    attrlist_t attrList;
    FInfoAttrBuf attrBuf;

    char *path = [filePath cStringUsingEncoding: NSUTF8StringEncoding];

    memset(&attrList, 0, sizeof(attrList));
    attrList.bitmapcount = ATTR_BIT_MAP_COUNT;
    attrList.commonattr  = ATTR_CMN_OBJTYPE | ATTR_CMN_FNDRINFO;

    int err = getattrlist(path, &attrList, &attrBuf, sizeof(attrBuf), 0);
    if (err != 0)
        return errno;

    // attrBuf.objType = (VREG | VDIR), inconsequential for invisibility

    UInt16 flags = CFSwapInt16BigToHost(attrBuf.finderInfo.file.info.finderFlags);

    if (isInvisible)
        flags |= kIsInvisible;
    else
        flags &= (~kIsInvisible);

    attrBuf.finderInfo.file.info.finderFlags = CFSwapInt16HostToBig(flags);

    attrList.commonattr = ATTR_CMN_FNDRINFO;
    err = setattrlist(path, &attrList, attrBuf.finderInfo.rawBytes, sizeof(attrBuf.finderInfo.rawBytes), 0);

    return err;
}

Я изменил этот код из ответа на этот вопрос, вы можете найти более полезную информацию там: Как сделать файл невидимым в Finder с помощью objective-C

Я не проверял этот код, но он должен работать. На самом деле, возможно, код не нужен, и просто сохранение файла с точкой перед именем файла будет работать.

Если у вас есть права администратора, вы можете выполнить sudo chmod в файле и установить его читать только если вы хотите, но вы не должны заставлять приложение запрашивать у пользователя пароль.


это решение сработало для меня очень хорошо. Попробуйте это:https://github.com/nielsmouthaan/SecureNSUserDefaults. Он будет хранить зашифрованный bool / string / float / integer в вашем файле UserDefaults. Надеюсь, это то, чего ты хочешь. Убедитесь, что вы загрузили и добавили CocoaSecurity (см. страницу SecureNSUserDefaults GitHub для ссылки для загрузки) в свой проект. CocoaSecurity является обязательным элементом SecureNSUSerDefaults, поэтому вам не нужно импортировать его ни в один из ваших файлов. Вы также должны скачать в base64, который является обязательным элементом CocoaSecurity. Вам также нужно добавить Base64 в свой проект, но не нужно импортировать его ни в один из ваших файлов.

использование

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

#import <SecureNSUserDefaults/NSUserDefaults+SecureAdditions.h>

затем установите ключ шифрования, вероятно, в вашем awakeFromNib метод:

[[NSUserDefaults standardUserDefaults] setSecret:@"your_secret_goes_here"];

я рекомендую генерировать случайную строку из чисел и буквы. Затем необходимо сохранить информацию в файле UserDefaults.

[[NSUserDefaults standardUserDefaults]
    setSecretObject:@"your_secret_object"
    forKey:@"the_key_your_object_will be_stored_under"];

чтобы получить строку, используйте этот метод:

NSString *retrievedData = [[NSUserDefaults standardUserDefaults]     
    secretStringForKey:@"the_key_your_object_will be_stored_under"];

надеюсь, это поможет!