Как безопасно хранить данные с помощью 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"];
надеюсь, это поможет!