OpenVPN później zrywa sesję OTP: czego wymaga ponowne uwierzytelnienie

Z perspektywy klienta wygląda to jak losowe rozłączenie godzinę po rozpoczęciu sesji roboczej. Ikona w zasobniku znika, tunel jest odbudowywany, a log pokazuje błąd uwierzytelnienia, a nie błąd sieci. W rzeczywistości sesja ponownie wynegocjowała parametry, a drugi handshake potrzebował poświadczeń, których klient nie miał już ważnej kopii. Kod jednorazowy, który zadziałał przy logowaniu, nie zadziała ponownie, więc wymiana kluczy zawodzi dokładnie tak, jak zaprojektowano.

Rozwiązaniem jest decyzja o tym, co ma przedstawić drugi handshake, a nie dłuższy timer ponownych prób.

Przejdź przez wymianę z punktu widzenia klienta

Przy logowaniu klient wysyła nazwę użytkownika, hasło i kod z urządzenia tokena, a serwer akceptuje tę kombinację. Potem sesja trwa, aż zadziała wyzwalacz ponownej negocjacji, który rozpoczyna nowy handshake TLS w istniejącym tunelu. Ten handshake ponownie prosi o uwierzytelnienie. Jeśli ścieżka uwierzytelniania serwera oczekuje hasła i bieżącego kodu jednorazowego, klient nie ma nowego kodu do przedstawienia, chyba że użytkownik jest obecny i go wpisze.

Większość klientów nie otwiera monitu w środku sesji, więc handshake kończy się przekroczeniem czasu i tunel pada. Użytkownik widzi ponowne połączenie, a nie monit uwierzytelnienia, dlatego pierwszy raport zwykle obwinia sieć.

auth-gen-token zmienia to, kto odpowiada na drugie pytanie

Opcja auth-gen-token pozwala serwerowi wydać token po udanym logowaniu, a późniejsze negocjacje przedstawiają ten token zamiast powtarzać hasło i kod. Podręcznik opisuje jego czas życia i zachowanie przy odnowieniu, a token trzeba traktować jako poświadczenie z własnym terminem ważności. W domyślnej ścieżce serwer sam waliduje token, zamiast ponownie wywoływać zewnętrzny autentykator haseł.

W przypadku integracji z zewnętrznym uwierzytelnianiem ten podział się zmienia. Wtyczka musi rozumieć stan tokena i stosować własne sprawdzenia, ponieważ serwer nie jest już jedynym komponentem decydującym o tym, czy sesja trwa. Traktowanie tokena jako kolejnego numerycznego kodu jednorazowego nie jest implementacją tej funkcji.

Zdecyduj, co dzieje się ze statusem konta

Token, który żyje dłużej niż dostęp konta, to dziura w polityce. Zdecyduj, jak wyłączone konto, usunięte członkostwo w grupie lub unieważnione urządzenie działają, gdy token jest jeszcze ważny. Krótkie czasy życia tokenów zmniejszają okno; jawna ścieżka unieważniania czyni je zamierzonym. Zapisz odpowiedź przed włączeniem opcji, ponieważ domyślna ścieżka nie konsultuje zewnętrznego autentykatora przy każdej ponownej negocjacji.

We wdrożeniu z wieloma serwerami sekret podpisywania tokenów musi być współdzielony, inaczej klient może zostać wysłany do węzła, który nie potrafi zweryfikować jego tokena.

Testuj wygaśnięcie i ponowne połączenie, nie tylko logowanie

Skróć interwał ponownej negocjacji w profilu testowym, aby drugi handshake nastąpił na twoich oczach, a potem śledź oba logi. Potwierdź, że token jest wydawany przy logowaniu, przedstawiany przy wymianie kluczy i odświeżany lub wydawany ponownie zgodnie ze skonfigurowanym czasem życia. Następnie wymuś wygaśnięcie tokena i pełne ponowne połączenie, bo klient, który czysto się łączy ponownie, nadal może zawodzić na ścieżce wymiany kluczy.

Usuwanie konta przetestuj na końcu. Ten przypadek mówi, czy zapisana polityka jest egzekwowana, czy tylko udokumentowana.

Nie naprawiaj tego, wyłączając odnowienie

Ustawienie interwału ponownej negocjacji na zero po obu stronach usuwa objaw i wraz z nim rotację kluczy. To ukrywa problem ponownego użycia poświadczeń za zmianą polityki, której nikt nie przejrzał. Zachowaj odnowienie i wybierz między tokenem wydanym przez serwer a nowym wyzwaniem interaktywnym w zależności od tego, czy użytkownik jest obecny.

Dłuższy timer ponownych prób nie sprawia, że zużyty kod znów jest ważny. Opóźnia tylko rozłączenie i utrudnia czytanie logu.