Hoe werkt Google Authenticator?

Google Authenticator ondersteunt zowel de HOTP en TOTP -algoritmen voor het genereren van eenmalige wachtwoorden.

Met HOTP delen de server en de client een geheime waarde en een teller, die wordt gebruikt om aan beide kanten een eenmalig wachtwoord onafhankelijk te berekenen. Telkens wanneer een wachtwoord wordt gegenereerd en gebruikt, wordt de teller aan beide kanten opgehoogd, zodat de server en de client gesynchroniseerd blijven.

TOTP gebruikt in wezen hetzelfde algoritme als HOTP met één groot verschil. De teller die in TOTP wordt gebruikt, wordt vervangen door de huidige tijd. De client en s erver blijven gesynchroniseerd zolang de systeemtijden hetzelfde blijven. Dit kan worden gedaan door het Network Time-protocol te gebruiken.

De geheime sleutel (evenals de teller in het geval van HOTP) heeft om op een bepaald moment aan zowel de server als de klant te worden gecommuniceerd. In het geval van Google Authenticator gebeurt dit in de vorm van een QRCode-gecodeerde URI. Zie: KeyUriFormat voor meer informatie.

Opmerkingen

• In het geval van HOTP, hoe weet Google Authenticator dat ik " " het wachtwoord heb gebruikt zonder te synchroniseren met de server? Wat Google Authenticator doet, is dat het verschillende sleutels blijft knipperen en dat ik ze gewoon kan gebruiken zonder feedback te geven op mijn mobiel.
• @MarioAwad Het antwoord daarop is te vinden op de HOTP RFC, sectie 7.4 . ietf.org/rfc/rfc4226.txt
• Bedankt voor het goed gedefinieerde antwoord en de follow-up. Korte samenvatting van sectie 7.4: Hersynchronisatie van de teller zo nu en dan en een vooruitkijkvenster voor de teller zorgen ervoor dat dingen werken zonder onmiddellijke synchronisatie.
• Zoals @TerryChia opmerkte, de geheime sleutel staat in de QR-code. Let op de gevoeligheid van de QRCode / Informatie. Ik heb een tijdje geleden een blogpost geschreven netknights.it/en/the-problem-with-the-google-authenticator

Werkend:

Authenticator implementeert het Time-Based One-Time Password (TOTP) -algoritme. Het heeft de volgende ingrediënten:

• Een gedeeld geheim (een reeks bytes)

• Een invoer afgeleid van de huidige tijd

• Een ondertekeningsfunctie

Gedeeld geheim: Het gedeelde geheim is wat u nodig heeft om het account op uw telefoon in te stellen . U maakt met uw telefoon een foto van een QR-code of u kunt het geheim handmatig invoeren.

Invoer (huidige tijd): De waarde voor de invoertijd die u gewoon van uw telefoon krijgt. Er is geen verdere interactie met de server vereist als u eenmaal het geheim hebt verkregen. Het is echter belangrijk dat de tijd van uw telefoon correct is aangezien de server zal in wezen herhalen wat er op uw telefoon gebeurt met behulp van de huidige tijd zoals bekend door de server.

Tekenfunctie: De ondertekeningsfunctie die wordt gebruikt is HMAC-SHA1. HMAC staat voor op hash gebaseerde berichtauthenticatiecode en het is een algoritme dat een veilige eenrichtingshashfunctie (in dit geval SHA1) gebruikt om een waarde te ondertekenen. Door een HMAC te gebruiken, kunnen we de authenticiteit verifiëren – alleen mensen die het geheim kennen, kunnen dezelfde uitvoer genereren voor dezelfde invoer (de huidige tijd).

OTP-algoritme :

Pseudocode:

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 

Referentie: https://garbagecollected.org/2014/09/14/how-google-authenticator-works/

Bekijk ook dit github-project voor GO-implementatie: https://github.com/robbiev/two-factor-auth/blob/master/main.go

Reacties

• Ondersteunt de Google-authenticator niet ' ook HOTP?

Het “zal werken aan een seed gebaseerd op tijd, dus het is vergelijkbaar met de manier waarop de RSA-sleutelhangers werken. d.w.z. ze hebben ook geen connectiviteit nodig.

Ik “heb even rondgekeken en dit wordt hier beantwoord: https://stackoverflow.com/questions/8340495/how-rsa-tokens-works

Als een strace de sshd daemon, kan men zien hoe de server “weet” over de geheime sleutel, terwijl hij het configuratiebestand van de gebruiker leest:

#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] 

De mobiele telefoon weet het al; je hebt het gescand via QR of getypt.

Opmerkingen

• Dit is een goed voorbeeld van hoe je kunt aantonen dat de tokens zijn niet naar de server gestuurd, maar ' niet echt uitleggen hoe het werkt (wat OP vroeg)
• Het doet niet ' t per se, maar het lost het gebrek aan connectiviteit op.