Autenticação da Web usando PKI Certs

Entendo a PKI razoavelmente bem do ponto de vista conceitual - ou seja, chaves privadas / chaves públicas - a matemática por trás delas, uso de hash e criptografia para assinar um certificado, Assinatura digital de transações ou documentos etc. Também trabalhei em projetos em que openssl As bibliotecas C foram usadas com certificados para garantir a comunicação e a autenticação. Também estou extremamente familiarizado com as ferramentas de linha de comando openssl.

No entanto, tenho muito pouca experiência com projetos habilitados para PKI baseados na Web e, portanto, estou tentando criar e codificar um projeto pessoal para entender melhor isso.

Os requisitos

Este é o site de um banco. Todos os usuários do Internet Banking podem usar qualquer certificado emitido por algumas CAs conhecidas (verisign, Thawte, confiar etc.). O Banco não é responsável por adquirir certificados para o usuário. Esses certificados serão usados ​​para autenticação no site dos bancos. As plataformas / SO etc ainda não foram corrigidas.

Projeto

Eu queria saber qual é a melhor maneira de fazer autenticação.

1. Eu vi que o Apache tem uma maneira de habilitar o SSL de 2 vias - nesse caso, acho que a navegação no site solicitaria automaticamente um certificado ao usuário. Mas não tenho certeza se isso é suficiente, porque parece que tudo o que verifica é se um certificado é assinado por uma CA confiável e também pode ser se ele se enquadra em uma lista branca de linhas de assunto dos certificados etc. Mas isso não é suficiente para um caso bancário, porque você precisa associar um ID do usuário do banco a um certificado.

2. O IIS parece ter uma maneira pela qual eu posso ter um certificado armazenado para cada usuário no Active Directory. Isso é o que eu entendi ao ler alguns artigos do MSDN. Você ativa o SSL bidirecional no IIS e, quando o usuário tenta navegar para o site, o IIS envia uma solicitação ao navegador com uma lista de CAs aprovadas e o navegador permite que o usuário escolha um certificado apropriado em seu armazenamento certeiro e o envie para back-end. Estou assumindo que o IIS fará duas coisas

   • Verifique se o usuário possui a chave privada correspondente ao certificado (nas negociações de cobertura)
   • Com base no mapeamento de certificado de usuário do AD, o IIS reportará o nome de usuário ao aplicativo.

3. Faça a autenticação explicitamente chamando funções de criptografia, dependendo da dependência do servidor da web para fazê-lo.

   • Mostre uma tela de usuário em que ele carrega um certificado e o aplicativo garante que o usuário tenha a chave privada correspondente ao certificado (solicitando ao front-end que assine alguma string usando o certificado).
   • O aplicativo possui um banco de dados, onde alguns dados são armazenados, permitindo que cada usuário seja mapeado para sua identificação de usuário. Isso pode ser
   • todo o certificado correspondente a cada ID do usuário
   • o número de série da CA e do certificado correspondente a cada ID de usuário.

Eu queria saber qual é o método mais usado? quais são as melhores práticas? Se eu for com o # 3, quais são as melhores maneiras de fazer isso?

Algo que também pode funcionar facilmente com aplicativos para smartphones será um bônus adicional.

Atualizar

Deixe-me esclarecer minha afirmação "codifique a parte da autenticação", porque algumas das respostas parecem indicar que ela foi mal interpretada - o que é ruim por não ser clara.

Isso não significa que eu mesmo escreva coisas criptográficas. Significa apenas que, na verdade, chamarei rotinas criptográficas explicitamente, em vez de depender do IIS ou de qualquer outro servidor da Web, implicitamente.

Embora eu realmente quisesse responder questão por questão, acho que abordarei este tópico por tópico:

Autorização / Autenticação

OK, primeiro as primeiras coisas. Para o seu exemplo, você precisa dos dois:

• Autenticação - prova de que o usuário é quem ele diz ser. Você escolheu a PKI, com a prova implícita de chave privada como sua autenticação.
• Autorização - conexão do usuário com o que ele está autorizado a fazer. Este é o ponto de conexão entre o login e o acesso às contas permitidas. O mapeamento do certificado para a conta e os recursos de acesso à conta é a autorização.

Em termos de autorização, você tem o problema de descobrir o processo pelo qual você conecta o DN do assunto do usuário à conta bancária. Dada a gravidade da transação, você definitivamente deseja ter um processo forte para isso, e não existe um caminho único aqui. Você precisaria consultar o banco e, provavelmente, os advogados, para descobrir como fazer isso de acordo com a política.

SSL, autenticação de cliente / servidor, prova de chave privada

O protocolo SSL sempre inclui autenticação do servidor, com uma configuração opcional adicional para autorização do lado do cliente. Você está certo com o número 1, pois o Apache oferece uma configuração que adiciona autenticação de cliente por PKI e você pode fornecê-lo com uma lista de CAs confiáveis. Durante a configuração de uma sessão SSL que requer autenticação de cliente via PKI - você obterá uma prova de chave privada.

A opção 1 ou 2 fornecerá isso - o Apache e o IIS podem ser configurados dessa maneira. Em relação às práticas recomendadas, eu adotaria qualquer uma das opções para implementar sua própria solução. O número 3 se aproxima perigosamente da regra "não escreva sua própria criptografia". Supondo que você possa vincular sua transação à presença de uma sessão SSL autenticada, não há motivo para fazer sua própria.

Além disso - nas opções 1 ou 2, há uma maneira de colocar todo o seu certificado em mãos e, a partir daí, para qualquer parte do certificado. Normalmente, o DN do sujeito e / ou o número de série do certificado são usados ​​para determinar a identidade do usuário para fins de autorização.

Em termos de "uso comum" - todos os principais servidores da web são bastante comuns. IIS, Apache, Tomcat e muitos outros podem ser configurados com SSL de autenticação do cliente. A decisão de lá é amplamente baseada na implementação geral. Todos os principais servidores da Web tiveram maneiras de obter acesso ao certificado fornecido na sessão SSL, que é o que você precisa para uma verificação mais detalhada.

Complementos de verificação de certificado

No mínimo, você precisará:

• configurar uma sessão SSL
• Pegue o certificado (a maioria dos servidores da web verificará a assinatura do certificado e a prova de chave privada)
• verifique a data de validade do certificado (não fornecida com nenhum servidor da web)
• execute a verificação de autorização para quais contas esse certificado pode acessar

Dadas as altas apostas bancárias, convém verificar o status de revogação do certificado - se a chave privada do usuário for perdida ou roubada, seu certificado deverá ser revogado.

O IIS pode ter os ganchos para uma verificação OCSP ou CRL - ele tende a ser um tipo de sistema mais abrangente (de mãos dadas!), Mas não me lembro de nada. Também não me lembro se isso forçará você a usar produtos da Microsoft para isso. Para o Apache, você quase certamente teria que codificar ou adicionar uma verificação de OCSP / CRL. Acredito que tenha ganchos durante o estabelecimento da sessão SSL - geralmente essa verificação é executada uma vez quando a sessão SSL é configurada.

Autorização

No primeiro e no segundo, você está certo de que o IIS possui algumas funcionalidades internas que vincularão o certificado fornecido na sessão SSL a um repositório do AD. É um dos casos em que a Microsoft faz um esforço extra para facilitar a compra e o uso de mais produtos. :) Existem nuances de como o IIS se vincula ao AD que estão além do escopo desta questão e além da minha lembrança imediata. Eu fiz algumas coisas bem loucas com o IIS e o AD, e meu pensamento geral é que, enquanto você faz algo relativamente simples, como extrair o nome de usuário com base no certificado de um repositório do AD - você provavelmente está bem. É quando você entra em questões mais complexas de armazenamento de dados, pesquisas estranhas no AD e coisas particularmente loucas (mas legítimas) com a PKI, você '

Com o IIS, mesmo assim - você precisará de algo adicionado à sua estrutura do AD ou de outro lugar, vinculando o nome de usuário à conta bancária. Normalmente, no setor bancário, um usuário tem várias contas. E dois usuários podem ter uma conta conjunta, portanto esse é um relacionamento de muitos para muitos.

Para o número 1 - sim, você precisa escrever sua própria pesquisa. Você precisa codificar: - um banco de dados ou hierarquia LDAP conectando o certificado ao usuário e o usuário às contas bancárias do usuário. A parte exclusiva garantida de um certificado é o número de série + DN do emissor. Frequentemente, o DN do sujeito funcionará, mas não é garantido em todos os sistemas PKI.

É assim que os desenvolvedores que usam PKI para autenticação de ponta com o Apache o fazem. Tendo trabalhado em vários desses sistemas, ainda não encontrei um caso de fácil reutilização de autorização, por isso nunca o vejo como um grande sinal negativo - vou ter que ter algo especializado de qualquer maneira, pois papéis / privilégios são nunca é fácil.

Isso soa como uma mistura dos itens 1 e 3 - meu forte conselho seria - usar os recursos nativos de qualquer aplicativo / servidor da web que você usar para gerar a sessão SSL. Isso permitirá que a configuração do navegador para o servidor com a consulta de certificado ocorra da maneira padrão, com as melhores práticas. A partir daí, com o Apache, você precisará criar seu próprio sistema de autorização. O IIS fornecerá a idéia da Microsoft de como isso deve funcionar para você.

Gotchas conhecidas

Faça vários testes no navegador. De ano para ano, navegador para navegador, encontro dicas com o tratamento de sessões SSL. O encadeamento correto da sessão SSL para a série de solicitações de páginas da web e a certeza de que o logout seja tratado corretamente são as maiores áreas de preocupação. E tem muito a ver com o servidor e o software do navegador. O SSL é estável o suficiente para que, quando funcione, geralmente funcione, embora possa haver problemas do IE vs. todos os outros.

Em particular, a última vez que fiz isso, a questão da codificação da força e do tempo limite da sessão foi muito importante.

Telefones inteligentes

Boa. Sorte. é tudo o que posso dizer. Não sou nem um desenvolvedor de aplicativos para dispositivos móveis, mas até agora minha impressão é que, em smartphones comuns, o tratamento de certificados PKI é insignificante ou inexistente.

Eu adoraria provar que estou errado.

Os certificados pessoais funcionam bem para renovação periódica de certificados (que possui um processo bastante robusto por trás) e podem ser implementados como uma autenticação "sem senha" que os clientes gostam

mas onde falha é

• O custo por certificado
• compatibilidade com navegadores modernos
• usuários finais extraindo certificados e armazenando chaves privadas de maneira insegura

esteja ciente de que certificados pessoais modernos com assinatura sha-2 não funcionam com o Safari no iPad e com muitos navegadores modernos. Isso ocorre porque os certificados pessoais nunca realmente decolaram como as organizações da autoridade de certificação pensavam que poderia. A emissão de 30.000 certificados (o que fazemos) custa aproximadamente o mesmo por certificado que alguns tipos de token de hardware.

Sua estratégia para permitir que os clientes encontrem seus próprios certificados não é realmente válida. Hoje em dia é difícil encontrar fornecedores de certificados pessoais e eles são muito caros - você precisa garantir que o business case funcione, caso contrário os clientes simplesmente não farão isso.

Ok, muita coisa acontecendo aqui. Primeiramente, a autenticação de certificado de cliente é inútil se não for suportada no nó de extremidade. Portanto, temos uma excelente postagem do Intrepidus, que aborda os conceitos básicos de autenticação de clientes para aplicativos para smartphones .

Em seguida, deixe-me sugerir que você não codifique sua própria rotina de autenticação. Existem muitas ótimas bibliotecas examinadas que lidam com isso. Você economizará recursos e erros de segurança executando uma biblioteca madura para autenticação. Usar uma biblioteca madura e aprovada para isso seria definitivamente uma prática recomendada.

A melhor prática a seguir é usar um diretório para manipular seu cliente: mapeamento de certificado. Então, você verá o AD ou LDAP. Como você mencionou, o Windows e o IIS tornam isso muito fácil para você. O IIS.net possui um bom resumo sobre a configuração do mapeamento de certificados no IIS .

Se você usa o Apache, isso não é tão fácil assim. Parece que mod_authz_ldap faz o mapeamento de certificado de cliente, mas eu não trabalhei pessoalmente com ele.

Isso nos leva à logística de realmente implementar algo assim. Você não está assinando os certificados dos usuários; portanto, é necessário um processo rígido para um usuário enviar seu certificado e fazer com que seu aplicativo o publique no diretório Eu gostaria de ver dois fatores para isso, com uma autenticação de senha e uma mensagem de texto ou ligação para um número confiável. Eu enviava um e-mail ao usuário para que ele soubesse que um certificado foi adicionado à sua conta. Permitiria que um usuário remova o mapeamento de certificado de usuário através da página de gerenciamento de contas no aplicativo.

Gostaria de ver o que o Google e o Facebook fazem para definir cookies para dispositivos confiáveis ​​para evitar dois fatores. Eu teria autenticação de novos dispositivos com dois fatores antes de permitir autenticação somente de certificado.

Eu também pensaria em como lidar com certificados de usuários que estão sendo revogados. Isso significa verificar uma lista de revogação de certificado externo (CRL). O que você faz se um certificado de cliente não tiver um ponto de distribuição de CRL definido? Você verifica a CRL sempre que o usuário efetua login ou de maneira programada como parte de um trabalho, pois provavelmente haverá apenas algumas CRLs em uso?

Realmente, isso se resume a: como sei que posso confiar que os documentos dos usuários não foram comprometidos e como posso mapear o certificado X para o usuário Y.