Como faço para armazenar dados com segurança com o objetivo C? (Mac/Cocoa Dev)

Question

Estou tentando criar uma parte de teste do meu aplicativo de cacau. Eu tenho o licenciamento tudo configurado (incluindo chaves) etc.

Mas eu estava me perguntando como poderia armazenar, por exemplo, na primeira vez em que o usuário executou o programa em um local seguro, onde o usuário não consegue encontrá -lo facilmente e/ou editá -lo.

Eu estava tendo um violino com o NSUserDefaults StandardUserDefaults, mas o usuário pode encontrar e editar facilmente esses dados na biblioteca> Preferências.

Answer 1

Eu argumentaria contra torná-lo super seguro. Uma vez tivemos uma ativação do servidor, mas afastamos completamente. Aqui estão alguns dos motivos:

• Até o método de armazenamento mais "seguro" pode ser quebrado
• Mesmo para um produto de nicho, uma rachadura pode ser desenvolvida, de maneira alguma, não importa o quão seguro seu método
• Existem poucos métodos muito caros e muito seguros. Todos os outros foram rachados
• Isso vai contra usuários justos e honestos, dificultando a corrigindo as coisas causando problemas
• Se um usuário faz quebrar seu software ou contornar sua segurança, ele provavelmente nunca terá comprado
• 80% dos usuários nem sabem o que é um arquivo de preferência
• 95% de todos os usuários não pensam na possibilidade de excluí -lo para estender o julgamento
• Uma maneira simples de redefinir períodos de teste massivamente facilita seu apoio aos usuários que você deseja fazer uma segunda tentativa por qualquer motivo
• Confiar em usuários é um bom ponto de venda
• Os usuários hidráulicos tendem a se voltar contra o software com muita proteção

Tenho certeza de que existem algumas, mas extremamente poucas, exceções desses pensamentos. Eu diria: não perca seu tempo com segurança de registro, mas dê

Answer 2

Você não pode usar um arquivo no sistema de arquivos. Qualquer pessoa que queira mexer/quebrar, será inteligente o suficiente para saber como rastrear o acesso ao arquivo através dos recursos básicos do OSX padrão. Então, um arquivo que está sendo adicionado está fora. Não apenas isso, mas é um comportamento ruim para criar arquivos que você não remove quando o aplicativo não é desinstalado. As pessoas não devem ter que ter recursos consumidos após excluir seu aplicativo de avaliação.

Como observado acima, mexer em seu pacote também é uma má idéia. Isso deixa você com três opções fundamentais.

1) Não se preocupe muito com isso. Use um sistema básico de expiração que use os locais e métodos padrão. Você ainda pode usar a criptografia nos dados que você armazena, mas sabe que isso também será quebrado. Aceite que a violação de direitos autorais ocorrerá, a menos que seu aplicativo seja totalmente impopular.

2) Use uma chamada de rede e faça a validação no servidor. Isso exigiria que o aplicativo sempre pudesse chegar ao seu serviço para ser executado. Esta não é uma boa ideia em geral. E se seus servidores estiverem baixos? E se eles estiverem off-line? E se um problema de rede entre você e eles acontecer? Todos esses cenários vão acontecer. Quando o fizerem, você provavelmente perderá clientes, a menos que seu aplicativo exija uma conexão com seus servidores que já operam (como digamos o Twitter ou o Facebook).

3) Seja um "mau cidadão", misturando -se com o pacote de aplicativos ou saindo de arquivos órfãos. Se você fizer isso, pelo menos, verifique se eles são claramente nomeados para se relacionarem com seu aplicativo, obviamente.

Por fim, a principal coisa a lembrar é que você não tem segurança na máquina de um usuário. Isso é deles. Isso significa que eles têm acesso físico que praticamente anula qualquer tentativa de impedir que eles cavassem. Você também pode olhar da seguinte maneira: quanto mais tecnicamente a mente, maior a probabilidade de você ficar mais inteligente do que todos nós e sua "segurança" será quebrada. Se você está projetando para um público não técnico, pode imaginar que, de um modo geral, eles não se incomodam em quebrá-lo ou procurando um.

Você pode gastar seus recursos para melhorar o aplicativo ou dar uma sensação melhor sobre as pessoas que não o usam após o período de teste. Um deles pode aumentar suas vendas e não o fará.

Editar] Também devo salientar que um dos meios mais comuns (se não os mais comuns) de quebrar essas coisas é modificar o binário. Então, ao quebrar a assinatura do código via pacote, você realmente se abriria para esse método, porque você teria quebrado uma das melhores proteções que tem. A maioria das rachaduras envolve binários sendo modificados de modo que a rotina que faz as verificações sempre retorna uma autenticação bem -sucedida.

Answer 3

Allan Odgaard tem um bastante decente escrever sobre como usar o OpenSSL para gerar/armazenar chaves de licença para software de cacau. Pode valer a pena ler.

Answer 4

Se precisar, uma maneira simples e comum é usar uma chave que é incorporada no aplicativo que criptografa um arquivo no disco que contém os dados sensíveis. O desafio é como tornar a chave segura.

Olhe para o Criptografia comum Biblioteca Digest.

Isso protegerá de quase todos os usuários casuais. Embora os hackers possam, com motivação suficiente, descobrir uma maneira de contornar.

Answer 5

Tente armazenar um arquivo com o nome, começa com um período em uma pasta e, em seguida, configure o sinalizador oculto do arquivo.

Um bom lugar para colocar o arquivo oculto seria um arquivo obscuramente nomeado na pasta Base da Pasta dos Usuários (~/), existem muitos arquivos ocultos obscuros, por isso é difícil saber qual você pode e não pode excluir. Exemplo de caminho: ~/.xdarwinprofile ou algo igualmente oficial soando.

Aqui está algum código que deve funcionar para ocultar o arquivo:

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

Modifiquei esse código da resposta para esta pergunta, você pode encontrar informações mais úteis lá:Como tornar um arquivo invisível no Finder usando o Objective-C

Não testei este código, mas deve funcionar. De fato, é possível que o código seja desnecessário e apenas salvar o arquivo com um ponto na frente do nome do arquivo funcionará.

Se você tiver privilégios de administrador, poderá executar um sudo chmod no arquivo e configurá -lo apenas para leitura, mas você não deve fazer com que seu aplicativo peça ao usuário a senha deles.

Answer 6

Esta solução funcionou muito bem para mim. Experimente isso: https://github.com/nielsmouthaan/securensuserdefaults. Ele armazenará o bool/string/float/float criptografado no seu arquivo userdefaults. Espero que seja isso que você quer. Certifique -se de baixar e adicione o CocoSeecurity (consulte a página do Github SecurensUserDefaults para o link de download) ao seu projeto. O CocoSeecurity é um elemento necessário do SecurensUserDefaults, para que você não precise importá -lo para nenhum dos seus arquivos. Você também deve baixar Base64, que é um elemento necessário de cocoSegurança. Você também precisa adicionar base64 ao seu projeto, mas não precisa importá -lo para nenhum de seus arquivos.

USO

Importe o arquivo de cabeçalho em qualquer lugar que desejar usar o método de criptografia.

#import <SecureNSUserDefaults/NSUserDefaults+SecureAdditions.h>

Em seguida, defina uma chave de criptografia, provavelmente em seu awakeFromNib método:

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

Eu recomendo gerar uma sequência aleatória de números e letras. Em seguida, você deve armazenar as informações no seu arquivo userdefaults.

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

Para recuperar a string, use este método:

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

Eu espero que isso ajude!