Como funciona o Google Authenticator?

O Google Authenticator oferece suporte para HOTP e TOTP algoritmos para gerar senhas de uso único.

Com HOTP, o servidor e o cliente compartilham um valor secreto e um contador, que é usado para calcular uma senha de uso único independentemente em ambos os lados. Sempre que uma senha é gerada e usada, o contador é incrementado em ambos os lados, permitindo que o servidor e o cliente permaneçam sincronizados.

TOTP usa essencialmente o mesmo algoritmo do HOTP, com uma diferença importante. O contador usado no TOTP é substituído pela hora atual. O cliente e s erver permanece em sincronia enquanto os tempos do sistema permanecem os mesmos. Isso pode ser feito usando o protocolo de tempo de rede .

A chave secreta (bem como o contador no caso de HOTP) tem para ser comunicado ao servidor e ao cliente em algum momento. No caso do Google Authenticator, isso é feito na forma de um URI codificado por QRCode. Consulte: KeyUriFormat para obter mais informações.

Comentários

• No caso de HOTP, como o Google Authenticator sabe que " usei " a senha sem sincronizar com o servidor? O que o Google Authenticator faz é continuar a piscar chaves diferentes e eu posso usar qualquer uma delas sem dar feedback ao meu celular.
• @MarioAwad A resposta para isso pode ser encontrada no HOTP RFC, seção 7.4 . ietf.org/rfc/rfc4226.txt
• Obrigado pela resposta bem definida e pelo acompanhamento. Resumo rápido da seção 7.4: Ressincronização do contador de vez em quando e uma janela de visualização para o contador é o que faz as coisas funcionarem sem a necessidade de sincronização instantânea.
• Como @TerryChia apontou, a chave secreta está no código QR. Esteja ciente da sensibilidade do QRCode / Informações. Escrevi uma postagem no blog há algum tempo netknights.it/en/the-problem-with-the-google-authenticator

Trabalhando:

O autenticador implementa o algoritmo de senha única baseada em tempo (TOTP). Ele tem os seguintes ingredientes:

• Um segredo compartilhado (uma sequência de bytes)

• Uma entrada derivada da hora atual

• Uma função de assinatura

Segredo compartilhado: O segredo compartilhado é o que você precisa obter para configurar a conta em seu telefone . Você tira uma foto de um código QR usando seu telefone ou pode inserir o segredo manualmente.

Entrada (hora atual): O valor do tempo de entrada que você simplesmente obterá de seu telefone, nenhuma outra interação com o servidor é necessária depois de obter o segredo. No entanto, é importante que o tempo de seu telefone seja exato como o servidor irá essencialmente repetir o que acontece no seu telefone usando a hora atual conhecida pelo servidor.

Função de assinatura: A função de assinatura usada é HMAC-SHA1. HMAC significa código de autenticação de mensagem baseado em Hash e é um algoritmo que usa uma função hash unilateral segura (SHA1 neste caso) para assinar um valor. Usar um HMAC nos permite verificar a autenticidade – apenas pessoas que conhecem o segredo podem gerar a mesma saída para a mesma entrada (a hora atual).

Algoritmo OTP :

Pseudo código:

original_secret = xxxx xxxx xxxx xxxx xxxx xxxx xxxx xxxx secret = BASE32_DECODE(TO_UPPERCASE(REMOVE_SPACES(original_secret))) input = CURRENT_UNIX_TIME() / 30 // sets a constant value for 30 seconds hmac = SHA1(secret + SHA1(secret + input)) //apply hashing offset = hmac[len(hmac)-1] & 0x0F //Last nibble four_bytes = hmac[offset : offset+4] //takes a subset of 4 bytes from 20 bytes large_integer = INT(four_bytes) //Covert four bytes to integer small_integer = large_integer % 1,000,00 //gives 6 digit code 

Referência: https://garbagecollected.org/2014/09/14/how-google-authenticator-works/

Verifique também este projeto github para implementação GO: https://github.com/robbiev/two-factor-auth/blob/master/main.go

Comentários

• Não ' o autenticador do Google também suporta HOTP?

Funcionará em uma semente com base no tempo, então é semelhante à maneira como Os porta-chaves RSA funcionam. ou seja, eles também não requerem nenhuma conectividade.

Acabei de dar uma olhada e a resposta está aqui: https://stackoverflow.com/questions/8340495/how-rsa-tokens-works

Se um strace for o sshd daemon, pode-se ver como o servidor “sabe” sobre a chave secreta, conforme lê o arquivo de configuração do usuário:

#strace -f -v -e open /usr/sbin/sshd -p 2222 -dddd -f /etc/ssh/sshd_config 2>&1 | grep -i goog > > [pid 2105] open("/home/myuser/.google_authenticator", O_RDONLY) = 4 > > [pid 2105] open("/home/myuser/.google_authenticator~", > > O_WRONLY|O_CREAT|O_EXCL|O_TRUNC|O_NOFOLLOW, 0400debug3: > > mm_sshpam_respond: pam_respond returned 1 [preauth] 

O telefone celular já sabe; você digitalizou via QR ou digitou.

Comentários

• Este é um bom exemplo de como demonstrar que os tokens são não está sendo enviado para o servidor, mas ' não explica realmente como funciona (que foi o que o OP pediu)
• Não ' per se, mas resolve a falta de conectividade.