Construindo um Sistema de Autenticação de Usuário MFA (Código de Componente de Inscrição) Usando Imagens

A maioria dos aplicativos interativos da Internet exige que o usuário primeiro seja “registrado” para usar o aplicativo e, em seguida, exige que o usuário “faça logon” sempre que desejar usar o aplicativo. Esse processo de primeiro inscrever um usuário e, posteriormente, reconhecer esse usuário para permitir o acesso pode ser descrito como Autenticação do usuário . Este artigo enfoca o código e os processos usados no componente de registro de nosso sistema de autenticação de usuário Authur .

Nosso portal de logon de demonstração permite que os usuários acessem um aplicativo criador de histórias em quadrinhos chamado Storybook, mas o próprio portal pode ser empregado em muitas situações em que a autenticação é necessária para usar um aplicativo da web.

O repositório de código do portal de logon

A base de código que descrevemos a seguir está disponível no GitHub como um repositório público em https://github.com/Bob-Wright/Authur-User-Registration-System . Comentários, críticas e sugestões são sempre bem vindos!

O portal de logon

O aplicativo construtor é iniciado a partir de uma galeria de histórias em quadrinhos que foram criadas pelo próprio construtor, e a primeira página do aplicativo é a página inicial do portal de logon mostrada aqui nestas duas capturas de tela a seguir. Esta página é apresentada pelo Portal.php na pasta Storybook.

Existem quatro opções de logon listadas em nossa caixa de diálogo principal, junto com um modal pop-up de explicação básica que descreve cada uma das opções de logon disponíveis através do botão “ OPÇÕES DE LOGIN EXPLICADAS ”.

Também está incluída na caixa de diálogo de logon uma opção para “ Alterar senha ” que está incluída aqui porque um motivo frequente para um usuário querer alterar sua senha é para que ele possa fazer logon.

O último item da caixa de diálogo é um convite do botão Inscrever- se para se inscrever como usuário.

Inscrever-se

Selecionar este botão Sign Up iniciará o programa signup.php e seremos apresentados com a caixa de diálogo nas três capturas de tela a seguir. Esta janela solicita informações de dados do usuário que serão usadas para criar uma entrada no banco de dados do perfil do usuário

Além de obter as informações de nome de usuário e endereço de e-mail, a caixa de diálogo solicita uma entrada de senha e, de acordo com a tradição, solicitamos uma combinação de caracteres alfanuméricos em maiúsculas e minúsculas junto com pelo menos um caractere de símbolo. A intenção de exigir esses parâmetros de caractere é obviamente tornar a senha mais difícil de adivinhar. Quão bem isso funciona é discutível.

Além das entradas de nome de usuário, e-mail e senha, a caixa de diálogo também reúne determinados itens de dados sobre cada usuário. Esses itens não contêm nominalmente dados de identificação pessoal, mas são planejados para fornecer uma pequena lista de fatores binários (sim/não) que podemos usar posteriormente no processo de validação. Então, por exemplo, podemos perguntar a um usuário específico “Você sabe nadar?” como um fator para identificá-los.

Depois que esses itens de dados forem fornecidos, podemos prosseguir clicando no botão “ Cadastre-se ” na parte inferior da tela. Isso resultará na exibição da tela a seguir, que nos informa que um e-mail de confirmação foi enviado ao usuário.

O e-mail mostrado aqui a seguir é enviado para o endereço de e-mail do novo usuário para verificação.

Todas as atividades de inscrição anteriores registram efetivamente um usuário em um sistema de logon de troca de token de e-mail/senha funcional completo que oferece suporte aos três primeiros métodos de logon (Nome de usuário/senha, Link mágico e Senha única) mostrados em nossa caixa de diálogo inicial do Portal.

A Seleção de Imagem do GateKeeper

Mas o código fica mais interessante a partir daqui, à medida que continuamos gerando um token de logon MFA baseado em imagem para o registro de nosso usuário. Clicar no botão “Verificar meu e-mail” no e-mail resultará na próxima tela do navegador mostrada abaixo sendo aberta pelo programa GateKeeper.php que reside na pasta Storybook/Portal . A página da web do programa GateKeeper primeiro informa ao usuário que seu e-mail foi verificado com sucesso e continua solicitando ao usuário que escolha uma imagem de avatar “gatekeeper” em uma galeria de imagens.

Incluído no repositório de código no GitHub está um programa de desenvolvedor utilitário chamado dumpSessionZ.php (ou dumpSession.php se você não usar o gerenciador de banco de dados de sessão Zebra session2DB incluído no repositório) que permitirá a exibição periódica do PHP $_SESSION variáveis à medida que os programas são executados. As próximas imagens são os resultados da execução do dumpSession na página do programa GateKeeper.php, como vemos acima, e traça o perfil da atividade do programa PHP em execução, permitindo-nos “acompanhá-lo”.

O aspecto principal da função do GateKeeper envolve a manipulação de várias matrizes de arquivos de imagem que usamos para preencher a galeria de seleção na tela. A intenção dessas maquinações é reorganizar a ordem de exibição das imagens da galeria aleatoriamente a cada carregamento de página. Se você observar o código GateKeeper.php , notará que inserimos uma armadilha de exceção na seção superior do código que seleciona as imagens a serem exibidas para que possamos especificar a inclusão de uma imagem de usuário específica na galeria. Isso nos permite ter certeza de que essa imagem pode ser selecionada como o avatar do gatekeeper do usuário da exceção de armadilha. Isso tem duas ramificações.

Em primeiro lugar, permite-me incluir especificamente minha própria foto pessoal no passo a passo de demonstração ☺ . Em segundo lugar, porém, fornece um local conveniente para inserir um shim que pode ser usado para tornar uma imagem específica disponível para qualquer usuário especificado.

No entanto, vamos continuar e assumir que nosso usuário clicou na imagem de avatar mostrada selecionada na tela do GateKeeper acima. Isso resulta na exibição da primeira página de informações de mugshot mostrada aqui a seguir. A imagem desta página é uma imagem JPEG carregada da pasta Storybook/Portal/ ckimages pelo programa Storybook/Portal/mugshotChoice.php .

Isso também resulta no acréscimo de mais alguns valores ao array de dados PHP $_SESSION, que podemos examinar atualizando nossa exibição dumpSession . De nota especial são as informações do banco de dados do usuário, incluindo o endereço de e-mail do usuário e nome e sobrenome junto com o valor dos fatores mostrados aqui a seguir.

Se clicarmos na imagem do Gatekeeper para continuar nosso registro de usuário, essa ação resultará em uma solicitação POST de formulário sendo emitida por mugshotChoice.php para nosso servidor Node PGP API . O terminal Node exibirá esta tela a seguir enquanto gera e salva um par de chaves PGP para este usuário e aguarda a próxima solicitação de API.

Quando a API conclui a geração da chave, ela salva as chaves em um banco de dados e retorna o usuário ao aplicativo principal por meio de um e-mail de aviso de conclusão da API PGP exibição de página da web mostrada a seguir que inclui a direção para carregar Storybook/Portal/showMugshotChoice.php . O código para o serviço Node API conforme instalado está incluído neste repositório de artigos na pasta Authur/openPGP e há mais informações sobre o próprio código da API neste artigo ( https://medium.com/@itzbobwright/some-openpgp- crypto-functions-on-a-node-api-server ) e seu repositório GitHub associado.

Essa configuração permite o uso de uma API que está em um domínio separado do aplicativo de logon e permite o uso do repositório openPGPjs NodeJS que você pode encontrar como uma bifurcação neste repositório GitHub em https://github.com/Bob -Wright/openpgpjs .

Vamos considerar alguns aspectos dessa separação que podemos aproveitar. Poderíamos ter nossa API de servidor de nó PGP em execução no mesmo servidor que nosso portal de logon. Outra consideração seria conectar o servidor de nó PKC ao servidor de aplicativo de logon por meio de um IP privado ou esquema de isolamento semelhante. Pode-se usar o endereço IP do servidor em oposição ao sistema DNS da Internet.

Mas, para continuar com a discussão do esquema atual, o usuário clicará na imagem conforme direcionado para carregar showMugshotChoice.php com a seguinte exibição de página como resultado.

Se fizermos uma atualização dumpSession nesta página, podemos ver mais quatro valores de dados anexados às variáveis de array $ _SESSION do PHP, conforme mostrado a seguir. A matriz agora inclui um valor para uma chave pública de estilo PGP que é armazenada com o valor da chave da matriz $_SESSION de [texto simples] junto com três outros valores para as chaves [coverImage] , [stegoImge] e [secretKey] . O valor [plaintext] , ou seja, o PGP PUBLIC KEY BLOCK , é recuperado de um banco de dados de chaves onde foi previamente escrito por nossa API Node PGP.

O programa showMugshotChoice.php usou esses valores para gerar a imagem mostrada na tela acima e esta imagem agora é uma nova imagem salva no formato PNG que foi codificada esteganograficamente para incorporar criptograficamente o valor PGP PUBLIC KEY BLOCK.

Neste momento, usamos a parte de registro ou inscrição de nosso Portal de logon para criar e salvar todas as informações que usamos atualmente em nosso sistema de autenticação de usuário baseado em MFA de autor e imagem . Se nosso usuário agora clicar na imagem conforme indicado, ele retornará a uma nova página do Portal de login com uma nova matriz $_SESSION limpa, conforme mostrado nas duas telas abaixo, e poderá prosseguir com o login no Storybook Comic Book Builder.

Antes de clicarmos em nossa segunda imagem de informações de mugshot e enquanto nosso array $_SESSION ainda estiver carregado, podemos desviar nossa atenção para o uso de outro programa também incluído na configuração de demonstração. Se navegarmos para a página Storybook/Portal/decodeStego.php , será apresentada esta tela a seguir, que mostra uma prova de extração de conceito do BLOCO DE CHAVE PÚBLICA codificado esteganograficamente e codificado para este usuário.

Como um resumo, essas próximas imagens são as capturas dumpSession completas para a página acima.

Conclusão

Isso conclui nosso exame do código usado no componente Enrollment ou Sign Up de nosso Sistema de Autenticação de Usuário MFA Baseado em Imagens Authur . A próxima e última seção de nosso código que consideraremos é a função do componente Login , na qual verificamos nosso usuário recém-registrado para acessar nosso aplicativo Storybook hospedado. Fique atento para o writeup esperançosamente em breve.

Para a próxima iteração do nosso Sistema de Autenticação de Usuário, a intenção é adicionar duas facilidades. A primeira facilidade seria incluir um método para usar programaticamente nossa imagem esteganográfica gerada para cunhar ou criar uma imagem NFT para usar como nossa imagem de token MFA. Uma consideração importante aqui é o custo e, para a demonstração, a cunhagem não deve ter taxa de gás. A segunda facilidade permitiria que um usuário carregasse sua própria imagem de avatar de gatekeeper, conforme fornecido por, digamos, um banco de dados de funcionários que podemos então converter para nosso formato Steganographic NFT.

Deixe-me oferecer alguns agradecimentos merecidos e PROPS a todos os codificadores benevolentes cujo trabalho gentilmente contribuiu para esse esforço. Por fim, agradeço a Deus e à minha família pelo excelente apoio!!

Também publicado aqui.