Wprowadzenie
Basic Authentication to jedna z najstarszych metod uwierzytelniania stosowana w protokołach HTTP i API. Choć jest prosta w implementacji, jej poważne ograniczenia sprawiają, że coraz więcej dostawców usług, takich jak Microsoft i Google, rezygnuje z jej stosowania. W niejszym artykule omówimy główne słabości tej metody oraz alternatywne podejścia do bezpiecznego uwierzytelniania.
W ramach przeprowadzonych przez naszą firmę testów bezpieczeństwa czesto obserwujemy stosowanie wspomnianej metody. W wielu przypadkach spotykamy się z oporem ze strony zespołów IT klientów, które argumentują, że jest to bezpieczna metoda, ponieważ wykorzystują szyfrowane połączenie (np. TLS). Jednak takie podejście pomija istotne słabości tego mechanizmu, takie jak podatność na ataki brute force oraz replay attacks, które mogą prowadzić do nieautoryzowanego dostępu do systemów.
Jak działa Basic Authentication?
Basic Authentication opiera się na przesyłaniu danych uwierzytelniających w nagłówku HTTP Authorization w formie przedstawionej poniżej:
Authorization: Basic <base64_encoded(username:password)>.
Po stronie serwera dane te są dekodowane i weryfikowane.
Przykładowy nagłówek HTTP z Basic Authentication:
Authorization: Basic dXNlcjpwYXNzd29yZA==
Gdzie dXNlcjpwYXNzd29yZA== to zakodowana wartość user:password za pomocą algorytmu Base64.
Jak można zauważyć z racji odwracalności procesu: zakodowana nie równa się zaszyfrowana.
Słabości Basic Authentication
Brak szyfrowania
Metoda Basic Authentication nie zapewnia natywnego szyfrowania przesyłanych danych. Bez użycia TLS (HTTPS), dane uwierzytelniające mogą zostać przechwycone i wykorzystane do ataków typu Man-in-the-Middle (MitM).
Powtarzalność danych logowania
Należy wspomnieć, że w ramach działania użytkownika, poświadczenia przesyłane są we wspomnianym nagłówku HTTP w każdym żądaniu wysyłanym do serwera. Co oznacza, że atakujący może je przechwycić i ponownie wykorzystać (tzw. atak „replay attack”). Trzeba też dodać, że w związku z powyższym poświadczenia są przechowywane w pamięci podręcznej („cache”) po stronie przeglądarki.
Przechowywanie danych uwierzytelniających po stronie klienta
Jak wspomniano, poświadczenia w tej metodzie przesyłane są co żądanie do serwera. W związku z powyższym poświadczenia są przechowywane w pamięci podręcznej („cache”) po stronie przeglądarki. Wiele aplikacji przechowuje dane logowania w pliku konfiguracyjnym lub localStorage, co może prowadzić do ich wycieku w przypadku kompromitacji systemu.
Brak stosowania mechanizmów obronnych
Metoda Basic Authentication domyślnie nie zapewnia podstawowych mechanizmów obronnych:
- brak automatycznego wylogowania użytkownika- przykładowo w ramach nieaktywności użytkownika w aplikacji, często stosowane jest wylogowywanie użytkownika po pewnym czasie. W przypadku Basic Authentication być to trudniejsze do zaimplementowania, ponieważ ta metoda nie korzysta z typowego mechanizmu sesji.
- brak ochrony przed atakami brute-force – każda próba logowania może być rejestrowana i wykorzystana do wielokrotnego odgadywania poprawnych poświadczeń z zastosowaniem metod siłowych.
- ataki typu replay – przechwycony i ponownie użyty nagłówek uwierzytelniający może pozwolić atakującemu na uzyskanie dostępu do chronionych zasobów.
- brak mechanizmów ograniczających czas życia poświadczeń – Basic Authentication nie stosuje znaczników czasu („timestamp”), TTL (Time-To-Live) ani mechanizmów unieważniania sesji, co oznacza, że przechwycone poświadczenia mogą być używane w nieskończoność.
- brak możliwości łatwego wycofania dostępu – w przeciwieństwie do tokenów sesyjnych czy mechanizmów OAuth, Basic Authentication nie zapewnia dynamicznej kontroli dostępu.
Dodatkowo należy wspomnieć, że metoda Basic Authentication nie zapewnia nowoczesnych mechanizmów bezpieczeństwa tj. mechanizmu uwierzytelniania wieloskładnikowego. Basic Authentication nie wspiera uwierzytelniania dwuskładnikowego (MFA), co znacznie obniża poziom zabezpieczeń i przykładowo nie daje zgodności z wymaganiami Strong Customer Authentication (SCA) w kontekście dyrektywy PSD2 (Payment Services Directive 2).
SCA, w kontekście przepisów PSD2, wymaga, aby uwierzytelnianie użytkownika w przypadku transakcji płatniczych lub dostępu do wrażliwych usług finansowych online odbywało się przy użyciu co najmniej dwóch z trzech czynników.
Współczesne zalecenia
Organizacje takie jak OWASP (Open Worldwide Application Security Project), NIST (National Institute of Standards and Technology) i CIS (Center for Internet Security) nie rekomendują stosowania metody Basic Authentication w nowoczesnych systemach uwierzytelniania.
Globalni gracze rezygnują z Basic Authentication?
Należy zauważyć, że globalni gracze technologiczni zrezygnowali już z implementacji tego typu metody w swoich produktach. Przykładowo:
- Microsoft od 1 października 2022 r. wyłączył Basic Authentication w usługach takich jak Exchange Online i Office 365, argumentując to względami bezpieczeństwa i rosnącą liczbą ataków bazujących na przechwytywaniu danych uwierzytelniających.
- Google od 30 września 2024 r. wycofuje Basic Authentication dla połączeń POP i IMAP, zastępując je mechanizmem OAuth 2.0, który zapewnia wyższy poziom bezpieczeństwa i wsparcie dla MFA.
Alternatywy dla Basic Authentication
Zamiast stosować Basic Authentication, wiele aplikacji i usług internetowych przechodzi na bardziej zaawansowane, bezpieczniejsze metody uwierzytelniania, które zapewniają lepszą ochronę przed atakami, takimi jak przechwycenie danych (np. Man-in-the-Middle) czy ataków siłowych haseł. Alternatywy dla Basic Authentication często wykorzystują różne mechanizmy, takie jak OAuth 2.0, JWT (JSON Web Token), OpenID Connect, API keys czy bardziej zaawansowane metody biometryczne.
OAuth 2.0 + OpenID Connect
OAuth 2.0 pozwala na autoryzację użytkowników bez przekazywania hasła w każdym żądaniu. OpenID Connect rozszerza OAuth 2.0 o mechanizmy identyfikacji (uwierzytelniania) użytkownika.
Tokeny JWT (JSON Web Token)
Tokeny JWT a wszczególności JSON Web Encryption (JWE) są szyfrowane i podpisane, co minimalizuje ryzyko ich przechwycenia i wykorzystania przez osoby trzecie.
SSL Client Authentication i Mutual TLS (mTLS)
SSL Client Authentication (uwierzytelnianie klienta za pomocą certyfikatu SSL/TLS) to jedna z najbezpieczniejszych alternatyw dla Basic Authentication, ponieważ opiera się na certyfikatach cyfrowych zamiast na loginie i haśle. Jest szeroko stosowana w systemach wymagających wysokiego poziomu bezpieczeństwa, np. w środowiskach korporacyjnych, bankowości elektronicznej czy API. Natomiast mechanizm Mutual TLS wymaga, aby obie strony (klient i serwer) uwierzytelniały się wzajemnie certyfikatami SSL/TLS. Jest to metoda spotykana np. w dostępach typu serwer-serwer, gdzie wymagany jesy
Podsumowanie i rekomendacje
Basic Authentication, mimo swojej prostoty, jest przestarzałym i niebezpiecznym mechanizmem uwierzytelniania. Współczesne organizacje, takie jak Microsoft i Google, rezygnują z tej metody na rzecz bardziej bezpiecznych alternatyw, takich jak OAuth 2.0, JWT i mTLS. Wdrożenie nowoczesnych mechanizmów uwierzytelniania jest kluczowe dla zapewnienia bezpieczeństwa systemów oraz ochrony danych użytkowników.
Nasze rekomendacje:
- Zastąpienie Basic Authentication mechanizmem OAuth 2.0 + OpenID Connect lub SSL Client Authentication w zależności od potrzby i możliwości.
- Wymuszanie korzystania z MFA, wszędzie tam gdzie to możliwe.
- Obowiązkowo wdrożenie szyfrowane połączenia TLS.
- Unikanie przechowywania poświadczeń w lokalnych plikach konfiguracyjnych.
Przejście na nowoczesne mechanizmy uwierzytelniania to nie tylko trend, ale konieczność wynikająca z rosnących zagrożeń w cyberprzestrzeni. Niestety, dla zespołów pentesterskich oznacza to mniej okazji do popisów– ale zawsze mogą spróbować złamać hasło do WiFi w biurze 😉.