Existe um melhor algoritmo .NET para criptografia de cartão de crédito?

StackOverflow https://stackoverflow.com/questions/41220

Pergunta

A rede System.Security.Cryptography namespace tem uma coleção bastante desconcertante de algoritmos que eu poderia usar para criptografar detalhes de cartão de crédito.Qual é o melhor?

Claramente precisa ser seguro para uma sequência relativamente curta.

EDITAR:Estou no Reino Unido, onde entendo que podemos armazenar detalhes criptografados de cartão de crédito, desde que o número CVV de três dígitos nunca seja armazenado.E obrigado a todos pelas ótimas respostas.

Foi útil?

Solução

Sem ofensa, mas a pergunta é um pouco “equivocada”.Não existe uma solução “bala de prata”.Eu recomendaria ler sobre criptografia em geral e depois fazer alguma modelagem de ameaças.Algumas perguntas (de forma alguma uma lista abrangente) que você deve se perguntar:

  • O módulo que está criptografando é aquele que precisa descriptografá-lo (neste caso, use criptografia simétrica) ou enviará dados para outro módulo (em outra máquina) que os utilizará (nesse caso, você deve considerar a chave pública criptografia)
  • Contra o que você deseja se proteger?Alguém acessa o banco de dados, mas não possui o código-fonte (nesse caso, você pode codificar a chave de criptografia diretamente na fonte)?Alguém está farejando sua rede local (você deve considerar soluções transparentes como o IPSec)?Alguém roubando seu servidor (isso pode acontecer até mesmo em data centers - nesse caso, a criptografia completa do disco deve ser considerada)?
  • Você realmente precisa manter os dados?Você não pode passá-lo diretamente para o processador do cartão de crédito e apagá-lo após receber a confirmação?Você não pode armazená-lo localmente no cliente em um cookie ou Flash LSO?Se você armazená-lo no cliente, certifique-se de criptografá-lo no lado do servidor antes de colocá-lo em um cookie.Além disso, se você estiver usando cookies, certifique-se de torná-los apenas http.
  • É suficiente comparar a igualdade dos dados (ou seja, os dados que o cliente me forneceu são os mesmos que eu)?Nesse caso, considere armazenar um hash dele.Como os números de cartão de crédito são relativamente curtos e usam um conjunto reduzido de símbolos, um salt exclusivo deve ser gerado para cada um antes do hash.

Editar mais tarde:observe que os algoritmos de criptografia padrão da mesma categoria (por exemplo, 3DES e AES - ambos sendo cifras de bloco simétrico) são de força comparável.A maioria dos sistemas (comerciais) não está quebrada porque alguém fez força bruta em sua criptografia, mas porque sua modelagem de ameaças não foi detalhada o suficiente (ou simplesmente eles não tinham nenhuma).Por exemplo, você pode criptografar todos os dados, mas se tiver uma interface da Web pública e vulnerável à injeção de SQL, isso não ajudará muito.

Outras dicas

Não importa.

Os números completos dos cartões nunca devem tocar no disco.

Tudo o que importa é o código de autenticação.

Para rastreamentos, etc., você usará apenas os últimos 4 dígitos xxxx xxxx xxxx 1234 e a data de validade.

Se você armazenar números de cartão, a escolha da criptografia será exigida pelo banco adquirente.

A menos que você seja o adquirente, nesse caso deve haver um antigo programador Unix/db2 a quem você deve perguntar.

"Você não pode armazená-lo localmente no cliente em um cookie" <- NUNCA

Eu acrescentaria que você simplesmente não deve armazená-los, a menos que tenha um motivo realmente bom para isso, e armazená-los em um cookie é um realmente má ideia - eles são apenas muito fácil para obter (o que acontece se alguém roubar um cookie - então não importa o quão criptografado ele seja).

Se você precisar repetir pagamentos, a maioria dos provedores de CC oferecerá uma maneira de fazer isso armazenando algum tipo de token do pagamento inicial, sem manter o número do cartão (você pode manter apenas os últimos 4 dígitos para exibir ao cliente para que saibam qual cartão está armazenado).

Sério, simplesmente não faça isso!

Além disso, você nunca deve manter o código CCV.

Conforme PCI-DSS regras de conformidade, qualquer padrão de criptografia líder do setor é suficiente.Portanto, um 3DES com chave de 256 bits é bom o suficiente (embora outros padrões possam ser usados).Veja isso http://pcianswers.com/2006/08/09/methods-of-encrypting-data/

Não se esqueça da integridade aqui.Existem ataques de falsificação contra criptografia pronta para uso quando o invasor não conhece a chave, mas pode manipular o texto cifrado.Isso pode ser particularmente desagradável quando:

  • criptografando strings curtas,
  • com substrings conhecidas

Esse é exatamente o caso dos cartões de crédito.Portanto, usar System.Security.Cryptography AES ou 3DES no modo CBC sem rolar sua própria soma de verificação pode ser perigoso.Ler:há alguma chance de um invasor sem a chave secreta substituir um número de cartão de crédito por outro.

Se estiver usando um gateway de pagamento de terceiros, não será necessário armazenar os números.

Não tem sentido.

3des é muito bom, armazene o salt ao lado e mantenha uma chave padrão em algum lugar que não seja no banco de dados ou em um arquivo de configuração.Dessa forma, se você for pego, eles não poderão descriptografá-lo.

Há também o aspecto jurídico a considerar.Não conheço a situação em outros lugares, mas na Alemanha você simplesmente não tem permissão para armazenar números de cartão de crédito1). Período. Não importa se você os criptografa ou não e em que formato você os armazena.

Todos vocês poderia O que fazer (e aqui estou me referindo de memória, sem nenhum conhecimento judicial) é armazenar um hash forte (SHA-256?) do número do cartão de crédito, junto com os últimos quatro dígitos e o número da conta.E sim, é trivial reconstruir o número completo apenas com essas informações.As leis nem sempre são lógicas.

1) Exceto se você for uma instituição de cartão de crédito certificada pelo governo federal.

Dica: Você deve investigar se é legal armazenar números de cartão de crédito.Na Suécia, por exemplo, você terá que ser certificado por PCI (indústria de cartões de pagamento), onde sua segurança interna e externa será testada (muito com muitas outras coisas).

Você deve pensar uma ou duas vezes antes de armazenar informações de cartão de crédito, pois os custos legais de fazer algo errado podem ser caros.

Criptografe o cartão de crédito com uma chave pública.Forneça a chave privada apenas à máquina processadora de pagamentos.A máquina processadora de pagamentos pode então consultar o banco de dados e fazer o trabalho, e ninguém mais, mesmo a máquina que adicionou a entrada, será capaz de descriptografá-la.

Algo como o openssl_seal do PHP, mas se você quiser, talvez com um algoritmo diferente.

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