Wytyczne te zawierają jednak wymagania dotyczące długości haseł, synchronizowanych uwierzytelniaczy (syncable authenticators), e-maila, kodów telefonicznych i SMS oraz limitów czasu sesji. Materiały przeanalizowane na potrzeby tego artykułu nie definiują, co uznaje się za odporne na phishing. Dlatego w tym objaśnieniu opisujemy to, co mówi tekst wytycznych, a naszą własną interpretację za każdym razem wyraźnie oznaczamy.
Czym są wytyczne NIST dotyczące uwierzytelniania i do kogo są skierowane
Ostateczna wersja SP 800-63B-4 nosi w historii dokumentu datę 31 lipca 2025 r., jak podaje strona publikacji NIST w serwisie csrc.nist.gov. Gdy przytaczamy w tym artykule jakieś wymaganie, wskazujemy, kto musi je spełnić, ponieważ wytyczne nakładają obowiązki na konkretne podmioty.
Wiele wymagań dotyczy weryfikatorów (verifiers) i dostawców usług poświadczeń (CSP), czyli podmiotów wymienionych w części wytycznych NIST poświęconej uwierzytelniaczom na pages.nist.gov. Inne odnoszą się do agencji federalnych. Przykładowo tekst wytycznych NIST na pages.nist.gov stanowi, że agencje federalne muszą wybrać co najmniej poziom AAL2, gdy dane osobowe są udostępniane online.
Nasza interpretacja: te zasady napisano z myślą o organizacjach, które obsługują systemy logowania, a nie jako instrukcje dla osób posiadających konta maklerskie, konta na giełdach czy skrzynki e-mail. Mimo to mogą pomóc czytelnikowi zrozumieć, jakie opcje logowania oferuje dana usługa i dlaczego. Same w sobie nie pokazują jednak, jak konkretna usługa chroni swoich użytkowników.
Hasło a MFA: czego tekst wymaga od haseł
Najbardziej jednoznaczna reguła dotycząca haseł w przeanalizowanych twierdzeniach odnosi się do haseł używanych samodzielnie. Zgodnie z częścią wytycznych NIST poświęconą uwierzytelniaczom na pages.nist.gov weryfikatorzy i CSP muszą wymagać, aby hasła używane jako jednoskładnikowy mechanizm uwierzytelniania miały co najmniej 15 znaków.
Dla kontekstu historycznego: FAQ NIST dotyczące tożsamości cyfrowej opisuje starszy model LOA. Według FAQ największa różnica między LOA1 a LOA2 w zakresie uwierzytelniaczy polegała na tym, że minimalna długość hasła wzrosła z sześciu do ośmiu znaków.
| Reguła w przeanalizowanych twierdzeniach | Źródło |
|---|---|
| Hasła jednoskładnikowe: co najmniej 15 znaków, wymagane przez weryfikatorów i CSP | Część NIST o uwierzytelniaczach |
| Stary model LOA: minimalna długość hasła wzrosła z sześciu do ośmiu znaków między LOA1 a LOA2 | FAQ NIST |
Nasza interpretacja: gdy hasło jest jedynym składnikiem, obecny tekst wymaga znacznie dłuższego minimum niż dawne wartości z modelu LOA. Przeanalizowane twierdzenia nie określają konkretnej długości haseł używanych jako jeden ze składników MFA, dlatego ten artykuł jej nie podaje.
Passkeys, synchronizowane uwierzytelniacze i AAL3
W przeanalizowanych twierdzeniach ani razu nie pada słowo „passkey”. Obejmują one natomiast pokrewną kategorię: synchronizowane uwierzytelniacze. Tekst wytycznych NIST na pages.nist.gov stanowi, że synchronizowanych uwierzytelniaczy nie wolno używać na poziomie AAL3, ponieważ wymagają one, aby klucz prywatny dało się eksportować.
To zdanie zawiera zarówno regułę, jak i jej podane uzasadnienie:
- Reguła: synchronizowane uwierzytelniacze są wykluczone na poziomie AAL3.
- Podane uzasadnienie: wymagają one, aby klucz prywatny dało się eksportować.
Czego ten artykuł nie może rozstrzygnąć na podstawie przeanalizowanych twierdzeń:
- Czy konkretny produkt sprzedawany lub oznaczany jako passkey jest synchronizowanym uwierzytelniaczem.
- Jak wytyczne traktują synchronizowane uwierzytelniacze na poziomach innych niż AAL3.
- Czy jakikolwiek passkey spełnia definicję odporności na phishing.
Nasza interpretacja: każdy, kto porównuje passkey z hasłem i MFA, powinien najpierw sprawdzić, czy dany passkey synchronizuje swój klucz. Właśnie na tej właściwości opiera się ta reguła. Ponieważ twierdzenia na tym się kończą, klasyfikację konkretnych passkeys pozostawiamy nierozstrzygniętą.
Kody e-mail, SMS i telefoniczne w logowaniu wieloskładnikowym
W przeanalizowanych twierdzeniach pojawia się kilka popularnych drugich kroków logowania. Część wytycznych NIST poświęcona uwierzytelniaczom na pages.nist.gov stanowi, że e-maila nie wolno używać do uwierzytelniania poza pasmem (out-of-band). Ta sama część mówi, że uwierzytelnianie poza pasmem należy uznać za nieważne, jeśli nie zostanie zakończone w ciągu 10 minut.
Kody telefoniczne i SMS omawia FAQ NIST dotyczące tożsamości cyfrowej. Według FAQ uwierzytelniacze korzystające z publicznej komutowanej sieci telefonicznej, w tym kody jednorazowe (OTP) przesyłane telefonicznie i SMS-em, mają status ograniczonych (restricted). Przeanalizowane twierdzenia nie wyjaśniają, co „ograniczone” oznacza w praktyce, dlatego ten artykuł nie opisuje tego dokładniej.
| Metoda | Co mówią przeanalizowane twierdzenia |
|---|---|
| E-mail w uwierzytelnianiu poza pasmem | Nie wolno go używać |
| Uwierzytelnianie poza pasmem ogólnie | Nieważne, jeśli nie zostanie zakończone w ciągu 10 minut |
| Kody OTP przesyłane telefonicznie i SMS-em | Ograniczone |
Nasza interpretacja: pod hasłem „MFA” kryje się kilka rodzajów drugiego kroku, a wytyczne traktują je różnie. Czytelnikowi przeglądającemu opcje logowania do skrzynki e-mail, konta maklerskiego czy konta na giełdzie to rozróżnienie może się przydać, ale te zasady nie mówią, z której opcji korzysta dana usługa ani jak dobrze ona działa.
Limity czasu ponownego uwierzytelnienia na poziomach AAL2 i AAL3
Zasady dotyczące sesji również różnią się w zależności od poziomu. Tekst wytycznych NIST na pages.nist.gov stanowi, że na poziomie AAL2 musi zostać ustalony określony ogólny limit czasu ponownego uwierzytelnienia i powinien on wynosić nie więcej niż 24 godziny. Na poziomie AAL3 ogólny limit czasu ponownego uwierzytelnienia musi wynosić nie więcej niż 12 godzin.
| Poziom | Ogólny limit czasu ponownego uwierzytelnienia |
|---|---|
| AAL2 | Musi zostać ustalony; powinien wynosić nie więcej niż 24 godziny |
| AAL3 | Musi wynosić nie więcej niż 12 godzin |
Warto zwrócić uwagę na sformułowania. Na poziomie AAL2 limit opisano słowem „should” (powinien), a na poziomie AAL3 słowem „must” (musi). Ten artykuł zachowuje tę różnicę, zamiast przedstawiać oba wymagania jako jednakowo wiążące.
Nasza interpretacja: jeśli usługa prosi o ponowne zalogowanie po pewnym czasie, może to wynikać z polityki limitu czasu tego rodzaju. Twierdzenia nie mówią jednak, jak poszczególne usługi ustalają swoje limity.
Co jest odporne na phishing i jak oceniać takie deklaracje
Przeanalizowane twierdzenia zaczerpnięte z tekstu wytycznych NIST na pages.nist.gov nie zawierają definicji odporności na phishing. Nie mówią też, czy passkeys, synchronizowane uwierzytelniacze lub jakakolwiek inna metoda taką definicję spełniają. Ten artykuł celowo pozostawia to pytanie otwarte. Nie zapożycza definicji z opracowań wtórnych, których nie objęła weryfikacja źródeł.
Ta ostrożność dotyczy deklaracji o bezpieczeństwie w ogóle. Poradnik z szybkimi wskazówkami CERT.br mówi, że plotka zwykle ma alarmistyczny ton, dotyczy tematów, które akurat przyciągają uwagę, i nie podaje źródła informacji albo powołuje się na nieznane źródła. Pokrewny nawyk, w naszej interpretacji: gdy wiadomość lub post twierdzi, że jakaś metoda logowania jest bezpieczna albo niebezpieczna, poszukaj tekstu źródłowego, na którym się opiera, i sprawdź, czy oryginalne sformułowanie mówi „must” (musi), „should” (powinien), czy coś słabszego.
Oto, na co ten artykuł może, a na co nie może odpowiedzieć w kwestii postawionego pytania:
- Odpowiedź na podstawie twierdzeń: zasady dotyczące długości haseł jednoskładnikowych, e-maila i czasu uwierzytelniania poza pasmem, kodów telefonicznych i SMS, synchronizowanych uwierzytelniaczy na poziomie AAL3 oraz limitów czasu ponownego uwierzytelnienia.
- Kwestie otwarte: definicja odporności na phishing oraz to, jak mieszczą się w niej konkretne passkeys.
Ograniczenia tego artykułu
Ten artykuł zawiera informacje edukacyjne na temat opublikowanych wytycznych dotyczących uwierzytelniania. Nie stanowi porady inwestycyjnej i nie rekomenduje żadnego produktu, brokera, giełdy ani usługi. Nie omawia części wytycznych NIST wykraczających poza wymienione tu twierdzenia i nie definiuje odporności na phishing. Nie ocenia, w jaki sposób konkretne konto lub usługa chroni swoich użytkowników.