Como posso usar o Delphi para criar um desafio / resposta visual para restaurar o acesso a um aplicativo?

Question

Estou interessado em criar um processo do tipo desafio / resposta em Delphi. O cenário é esse ... temos 2 computadores ... 1 pertence ao usuário e 1 pertence a um técnico de suporte.

O usuário está bloqueado de um determinado programa e, para obter 1 acesso a tempo, eu quero:

1. O usuário a ser apresentado com uma frase de desafio, como "28394ldJA9281dhq" ou algum tipo de valor razoavelmente exclusivo
2. O usuário chamará a equipe de suporte e lerá esse desafio (depois que a equipe de suporte validou sua identidade)
3. A pessoa de suporte digitará esse valor de desafio em um programa em seu sistema que gerará uma resposta, algo igualmente tão único quanto a resposta, como "9232KLSDF92SD"
4. O usuário digita a resposta e o programa determina se essa é ou não uma resposta válida.
5. Se for, o usuário recebe 1 acesso ao aplicativo.

Agora, como fazer isso é a minha pergunta? Terei 2 aplicativos que serão não têm acesso em rede um ao outro. Existe alguma funcionalidade no Windows que possa me ajudar com esta tarefa?

Eu acredito que posso usar alguma funcionalidade dentro Criptoapi, mas eu realmente não tenho certeza por onde começar. Eu apreciaria qualquer ajuda que você poderia oferecer.

Answer 1

Eu implementaria uma autenticação de resposta de desafio baseada no MD5.

A partir de Wikipedia http://en.wikipedia.org/wiki/cram-md5

Protocolo

1. Desafio: Na autenticação CRAM-MD5, o servidor envia primeiro uma string de desafio para o cliente.
2. Resposta: O cliente responde com um nome de usuário seguido por um personagem espacial e depois um resumo de 16 bytes na notação hexadecimal. O Digest é a saída do HMAC-MD5 com a senha do usuário como chave secreta e o desafio original do servidor como mensagem.
3. Comparação: o servidor usa o mesmo método para calcular a resposta esperada. Se a resposta dada e a correspondência de resposta esperada, a autenticação foi bem -sucedida.

Isso fornece três tipos importantes de segurança.

1. Primeiro, outros não podem duplicar o hash sem conhecer a senha. Isso fornece autenticação.
2. Segundo, outros não podem reproduzir o hash - depende do desafio imprevisível. Isso é chamado de frescura ou prevenção de reprodução de várias formas.
3. Terceiro, os observadores não aprendem a senha. Isso é chamado de sigilo.

As duas características importantes deste protocolo que fornecem esses três benefícios de segurança são o hash unidirecional e o novo desafio aleatório.

Além disso, você pode adicionar alguma identificação de aplicativos à string de desafio, para uma verificação dupla no remetente do desafio.

IMPORTANTE: Tem algumas fraquezas, avalie cuidadosamente como eles podem afetá -lo.

Answer 2

Em relação ao desafio verbal/estratégia de resposta: usamos essa abordagem para licenciar um aplicativo de nicho em cinco mil estações de trabalho em todo o mundo por mais de dez anos. Nossa equipe de suporte chamou de "códigos de lançamento de mísseis" devido à sua semelhança com o processo de autenticação de lançamento de mísseis clássicos visto em filmes antigos.

Esta é uma maneira extremamente demorada de proteger seu programa. Ele consumia enormes quantidades de tempo de nossas equipes e clientes lendo os códigos de e para os usuários. Todos eles odiavam.

Sua situação/contexto pode ser diferente. Talvez você não o use com tanta frequência quanto nós. Mas aqui estão algumas sugestões:

1. Considere cuidadosamente o comprimento e o conteúdo do código: a maioria dos usuários (e a equipe de suporte) se ressente de digitar muitos caracteres. Muitos usuários são maus datilógrafos. Considere se uma corda longa e incluindo marcas de pontuação e sensibilidade ao caso os sobrecarregar indevidamente em comparação com a quantidade de segurança adicionada.

2. Depois de anos usando uma implementação de desafio/resposta verbal, deixamos-o no local (como uma queda), mas adicionamos um sistema automatizado simples. Optamos por usar o FTP em vez de uma abordagem da Web mais sofisticada, para que não precisássemos ter nenhum software em execução em nosso servidor interno (ou lidar com nossa equipe de TI!)

Basicamente, usamos arquivos FTP para fazer a troca que foi feita anteriormente no telefone. O servidor coloca um arquivo no servidor FTP que contém a frase do desafio. O nome do arquivo é o nome do cliente. Nossa equipe de suporte possui um programa que cria automaticamente esse arquivo em nosso site FTP.

O cliente é instruído por nossa equipe a atingir uma chave quente que lê o arquivo FTP, a autentica e coloca um arquivo de resposta no servidor.

O software de nossos funcionários de suporte está pesquisando o software do cliente para criar o arquivo de resposta. Quando ele vê o arquivo, ele o faz o download e confirma seu conteúdo e o exclui do servidor.

É claro que você pode fazer com que essa troca aconteça quantas vezes e em qualquer direção necessária em uma determinada sessão para atingir seus objetivos.

Os dados nos arquivos podem ter as mesmas teclas MD5 que você usaria verbalmente, para que seja tão seguro quanto você deseja.

Uma fraqueza neste sistema é que o usuário precisa ter acesso ao FTP. Descobrimos que a maioria de nossos usuários (todas as empresas) tem acesso à FTP disponível. (Obviamente, sua base de clientes pode não ...) Se nosso aplicativo no campo não puder acessar nosso site FTP, anuncia claramente o problema para que nosso cliente possa ir à equipe de TI solicitar que eles abram o acesso. Enquanto isso, acabamos de voltar aos códigos verbais.

Utilizamos as ferramentas FTP de baunilha simples sem problemas.

Sem dúvida, existem algumas fraquezas nessa abordagem (provavelmente incluindo algumas em que não pensamos.) Mas, para nossas necessidades, foi fantástico. Nossa equipe de suporte e clientes adoram.

Desculpe se nada disso é relevante para você. Espero que isso ajude você a alguns.