Jak działa Google Authenticator?

Google Authenticator obsługuje zarówno HOTP i algorytmy TOTP do generowania haseł jednorazowych.

W przypadku HOTP serwer i klient mają wspólną tajną wartość i licznik, który służy do obliczania hasła jednorazowego niezależnie po obu stronach. Za każdym razem, gdy hasło jest generowane i używane, licznik jest zwiększany po obu stronach, dzięki czemu serwer i klient pozostają zsynchronizowane.

TOTP zasadniczo używa tego samego algorytmu co HOTP z jedną zasadniczą różnicą. Licznik używany w TOTP jest zastępowany przez aktualny czas. Klient is erver pozostają zsynchronizowane, o ile czasy systemowe pozostają takie same. Można to zrobić za pomocą protokołu Network Time .

Tajny klucz (podobnie jak licznik w przypadku HOTP) ma być w pewnym momencie przekazane zarówno serwerowi, jak i klientowi. W przypadku Google Authenticator odbywa się to w postaci URI zakodowanego w QRCode. Zobacz: KeyUriFormat , aby uzyskać więcej informacji.

Komentarze

• W przypadku HOTP, skąd Google Authenticator wie, że " użyłem " hasła bez synchronizacji z serwerem? To, co robi Google Authenticator, polega na tym, że nadal miga różnymi klawiszami i mogę po prostu użyć dowolnego z nich bez przekazywania opinii na mój telefon komórkowy.
• @MarioAwad Odpowiedź na to pytanie można znaleźć w dokumencie HOTP RFC, sekcja 7.4 . ietf.org/rfc/rfc4226.txt
• Dziękuję za dobrze określoną odpowiedź i dalsze uwagi. Krótkie podsumowanie sekcji 7.4: Ponowna synchronizacja Licznika od czasu do czasu, a okno wyprzedzające dla licznika sprawia, że wszystko działa bez konieczności natychmiastowej synchronizacji.
• Jak zauważył @TerryChia, tajny klucz znajduje się w kodzie QR. Bądź świadomy wrażliwości QRCode / informacji. Niedawno napisałem post na blogu netknights.it/en/the-problem-with-the-google-authenticator

Praca:

Authenticator implementuje algorytm Time-Based One-Time Password (TOTP). Zawiera następujące składniki:

• Wspólne hasło (sekwencja bajtów)

• Dane wejściowe pochodzące z bieżącego czasu

• Funkcja podpisująca

Wspólny sekret: Wspólny sekret to to, co musisz uzyskać, aby skonfigurować konto w telefonie . Albo zrobisz zdjęcie kodu QR telefonem, albo możesz wprowadzić sekret ręcznie.

Dane wejściowe (aktualna godzina): Wprowadzona wartość czasu, którą uzyskasz po prostu z telefonu, po uzyskaniu sekretu nie jest wymagana żadna dalsza interakcja z serwerem. Ważne jest jednak, aby czas telefonu był dokładny jako serwer zasadniczo powtórzy to, co dzieje się na Twoim telefonie, używając aktualnego czasu znanego z serwera.

Funkcja podpisywania: Używana funkcja podpisywania to HMAC-SHA1. HMAC oznacza kod uwierzytelniania wiadomości oparty na skrótach i jest to algorytm, który wykorzystuje bezpieczną jednokierunkową funkcję skrótu (w tym przypadku SHA1) do podpisania wartości. Korzystanie z HMAC pozwala nam zweryfikować autentyczność – tylko osoby znające sekret mogą wygenerować te same dane wyjściowe dla tego samego wejścia (aktualnego czasu).

Algorytm OTP :

Pseudokod:

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 

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

Sprawdź również ten projekt github pod kątem implementacji GO: https://github.com/robbiev/two-factor-auth/blob/master/main.go

Komentarze

• Czy nie ' czy google Authenticator obsługuje również HOTP?

Będzie działać na podstawie czasu, więc jest podobny do sposobu Breloki RSA działają. tj. nie wymagają też żadnej łączności.

Właśnie się rozejrzałem i oto odpowiedź: https://stackoverflow.com/questions/8340495/how-rsa-tokens-works

Jeśli strace z sshd demonie, można zobaczyć, skąd serwer „wie” o tajnym kluczu, czytając plik konfiguracyjny użytkownika:

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

Telefon komórkowy już to wie; zeskanowałeś go za pomocą QR lub wpisałeś.

Komentarze

• To jest dobry przykład, jak zademonstrować, że tokeny są nie jest wysyłany na serwer, ale nie ' nie wyjaśnia, jak to działa (o co prosił OP)
• Nie ' t per se, ale rozwiązuje problem braku łączności.