oathtool nunca concorda com o Google Authenticator

oathtool nunca concorda com o Google Authenticator

Atualmente, uso o Google Authenticator para 2FA, coisas como conexão com VPN, etc. Queria ver se conseguia obter o código de seis dígitos na minha caixa OSX, mas por algum motivo oathtoolnunca retorna o mesmo valor do Authenticator. E o código do autenticador funciona, o oathtooloutro não.

Curiosamente, também tentei em um simulador iOS comhttps://github.com/mattrubin/Authenticatorno mesmo sistema e o código que ele produz concorda oathtoole não com o Autenticador.

Suspeitei que talvez fosse um problema de sincronização de horário, mas depois de sincronizar manualmente meu horário OSX, o código é o mesmo. Estou me perguntando se talvez existam parâmetros padrão no algoritmo TOTP que não correspondam, mas não sei quais seriam.

O oathtoolcomando gera algo como o seguinte

% oathtool --verbose --base32 --totp "$SECRET"
Hex secret: ...
Base32 secret: ...
Digits: 6
Window size: 0
Step size (seconds): 30
Start time: 1970-01-01 00:00:00 UTC (0)
Current time: 2016-10-20 22:27:22 UTC (1477002442)
Counter: 0x2EF3E06 (49233414)

(Observe que $SECRETacima está o mesmo valor usado para gerar o código QR que o Authenticator usou.)

Alguma razão pela qual eles não concordariam?

Atualizar

Tentei mexer no tempo de 30 segundos em cada lado do tempo do meu sistema usando

oathtool --now "$(perl -e'use DateTime; print DateTime->now()->subtract(seconds=>30)->strftime( "%Y-%m-%d %H:%M:%S %Z" )')" -b --totp $SECRET -w 20|sort

O perl acima gera tempo no formato de

2016-10-20 23:36:15 UTC

Também produzi 20 números de cada vez, mas nenhum deles parecia corresponder ao que tenho no Authenticator.

Responder1

Já que a pesquisa por "Google Authenticator oathtool" leva você até aqui, e a resposta está parcialmente nos comentários, por conveniência e integridade...

oathtoole o Google Authenticator são implementações deRFC 6238 TOTP. TOTP produz uma saída de 6 dígitos usando um HMAC. Embora o cliente Android oficial não seja mais de código aberto, não é porque a implementação do TOTP mudou ou é “secreta”.

Existem 2 entradas para o HMAC, um número e um segredo. No TOTP, o número é a contagem de intervalos de tempo de uma época, os padrões para ambos oathtoole GA são intervalos de 30 segundos (tamanho do "passo de tempo") e 01/01/1970 00:00:00 UTC. Para ser claro, oathtoolo GA concordará, desde que os parâmetros concordem: a época e o tempo devem ser suficientemente próximos, e o intervalo de tempo e o segredo devem corresponder.

Quando necessário (por exemplo, alguns tokens TOTP de hardware usam um intervalo de 60 segundos), você pode usar -spara definir o tamanho do intervalo e, para acomodar o deslocamento/desvio, você pode substituir o que oathtool pensa ser "agora" (ou falsificar a época).

Para solucionar problemas, o seguinte é útil:

oathtool -v --now  "now -30 minutes" -w 120 --totp $SECRET

Para um intervalo de 30 segundos, isso gerará uma hora inteira de valores, de 30 minutos atrás até 30 minutos no futuro. A partir disso você pode deduzir um deslocamento de token ou um deslocamento de relógio ( diff -ycomparar as saídas lado a lado pode ser útil). O TOTP usa "horário unix", portanto, os fusos horários não devem ser um problema, a menos que um fuso horário esteja "ocultando" algum grande deslocamento de um relógio incorreto.

--nowe --epochusar o robusto analisador de data e hora GNU e suportar especificações de tempo relativo, bem como carimbos de data e hora absolutos, --now "30 min ago"também funciona.

Conforme determinado pelo OP, para a época e o intervalo de tempo padrão, se a hora estiver correta, então deve ser o segredo que não está.

Responder2

Sincronizei o Google Authenticator e o oathtool:

secret=`echo 1234567812345678 | base32`
oathtool -v --totp -b $secret
qrencode -t ANSI "otpauth://totp/test?secret="${secret}""

informação relacionada