Pergunta

Temos uma situação em nosso produto onde por muito tempo alguns dados foram armazenados no banco de dados do aplicativo como string SQL (escolha entre servidor MS SQL ou sybase SQL em qualquer lugar) que foi criptografado através da função API do Windows Criptografar. (direto e descriptografável)

O problema é que o CryptEncrypt pode produzir NULLs na saída, o que significa que quando for armazenado no banco de dados, as manipulações da string irão, em algum momento, truncar o CipherText.

Idealmente, gostaríamos de usar um algoritmo que produza CipherText que não contenha NULLs, pois isso causará o mínimo de alterações nos bancos de dados existentes (alterando uma coluna de string para binário e código para lidar com binário em vez de strings) e apenas descriptografar os dados existentes e criptografá-los novamente com o novo algoritmo no momento da atualização do banco de dados.

O algoritmo não precisa ser o mais seguro, pois o banco de dados já está em um ambiente razoavelmente seguro (não em uma rede aberta/inter-webs), mas precisa ser melhor que o ROT13 (que quase posso descriptografar na minha cabeça agora!)

editar:aliás, algum motivo específico para alterar o texto cifrado para texto cifrado?o texto cifrado parece mais amplamente usado ...

Foi útil?

Solução

Qualquer algoritmo semi-decente terá uma grande chance de gerar um valor NULL em algum lugar do texto cifrado resultante.

Por que não fazer algo como codificação base-64 seu blob binário resultante antes de persistir no banco de dados?(exemplo de implementação em C++).

Outras dicas

Armazenar um hash é uma boa ideia.No entanto, por favor, leia definitivamente o livro de Jeff Você provavelmente está armazenando senhas incorretamente.

Essa é uma rota interessante, JO.Estamos analisando a viabilidade de um método não reversível (ainda garantindo que não recuperamos explicitamente os dados para descriptografar), por exemplo.basta armazenar um Hash para comparar em um envio

Parece que o desenvolvedor que está lidando com isso irá envolver a criptografia existente com yEnc para preservar a integridade da tabela, pois os dados precisam ser recuperáveis, e isso evita toda aquela bagunça com improváveis ​​infinitos....uhhh alterando os tipos de coluna em instalações entrincheiradas.Saúde Gente

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top