Uwierzytelnianie oparte na formularzu dla stron internetowych

Uważamy, że przepełnienie stosu powinno być nie tylko źródłem bardzo szczegółowych pytań technicznych, ale także ogólnych wskazówek dotyczących rozwiązywania różnych typowych problemów. „Uwierzytelnianie oparte na formularzu dla stron internetowych” powinno być dobrym tematem takiego eksperymentu.

Powinien zawierać takie tematy jak:

• Jak się zalogować
• Jak się wylogować
• Jak pozostać zalogowanym
• Zarządzanie plikami cookie (w tym zalecane ustawienia)
• Szyfrowanie SSL / HTTPS
• Jak przechowywać hasła
• Korzystanie z tajnych pytań
• Zapomniałem nazwy użytkownika / hasła
• Wykorzystanie elementów jednorazowych w celu zapobiegania fałszerstwom żądań między witrynami (CSRF)
• OpenID
• Pole wyboru „Pamiętaj mnie”
• Autouzupełnianie nazw użytkowników i haseł w przeglądarce
• Tajne adresy URL (publiczny adres URL chroniony przez skrót)
• Sprawdzanie siły hasła
• Sprawdzanie poprawności wiadomości e-mail
• i wiele więcej o uwierzytelnianiu opartym na formularzu ...

Nie powinno obejmować takich rzeczy jak:

• Role i autoryzacja
• Podstawowe uwierzytelnianie HTTP

Pomóż nam:

1. Sugerowanie podtematów
2. Przesyłanie dobrych artykułów na ten temat
3. Edycja oficjalnej odpowiedzi

CZĘŚĆ I: Jak się zalogować

Zakładamy, że już wiesz, jak zbudować formularz logowania + hasło HTML, który POST zapisuje wartości do skryptu po stronie serwera w celu uwierzytelnienia. Poniższe sekcje zajmą się wzorcami prawidłowego uwierzytelniania dźwięku i sposobem uniknięcia najczęstszych pułapek bezpieczeństwa.

Do HTTPS czy nie do HTTPS?

O ile połączenie nie jest już bezpieczne (to znaczy tunelowane przez HTTPS przy użyciu SSL / TLS), twoje wartości formularza logowania zostaną wysłane w postaci jawnego tekstu, co pozwoli każdemu podsłuchującemu połączenie między przeglądarką a serwerem internetowym będzie mogło czytać loginy podczas przechodzenia przez. Tego rodzaju podsłuchy są rutynowo wykonywane przez rządy, ale ogólnie rzecz biorąc, nie zajmiemy się „własnymi” kablami inaczej niż mówiąc: Po prostu użyj HTTPS.

Zasadniczo jedynym praktycznym sposobem ochrony przed podsłuchiwaniem / podsłuchiwaniem pakietów podczas logowania jest użycie HTTPS lub innego schematu szyfrowania opartego na certyfikatach (na przykład TLS ) lub sprawdzonego i przetestowanego schematu wyzwanie-odpowiedź (na przykład Diffie-Hellman na bazie SRP). Każdą inną metodę można łatwo obejść przez podsłuchującego.

Oczywiście, jeśli chcesz uzyskać nieco niepraktyczne podejście, możesz również zastosować jakąś formę dwuskładnikowego schematu uwierzytelniania (np. Aplikację Google Authenticator, fizyczny słownik kodów „zimnej wojny” lub klucz generatora kluczy RSA). Przy prawidłowym zastosowaniu może to działać nawet przy niezabezpieczonym połączeniu, ale trudno sobie wyobrazić, że deweloper byłby skłonny wdrożyć uwierzytelnianie dwuskładnikowe, ale nie SSL.

(Nie) Rzuć własne szyfrowanie / mieszanie JavaScript

Biorąc pod uwagę postrzegany (choć obecnie możliwy do uniknięcia ) koszt i trudności techniczne związane z konfiguracją certyfikatu SSL w Twojej witrynie, niektórzy programiści mają pokusę, aby wprowadzić własne schematy szyfrowania lub szyfrowania w przeglądarce, aby uniknąć przekazywania logowanych tekstów jawnych przez niezabezpieczony przewód.

Chociaż jest to szlachetna myśl, jest w zasadzie bezużyteczna (i może być wadą bezpieczeństwa ), chyba że jest połączona z jednym z powyższych - to znaczy zabezpieczeniem linii za pomocą silnego szyfrowania lub użyciem wypróbowanej i przetestowanej odpowiedzi na wyzwanie mechanizm (jeśli nie wiesz, co to jest, po prostu wiedz, że jest to jeden z najtrudniejszych do udowodnienia, najtrudniejszych do zaprojektowania i najtrudniejszych do wdrożenia pojęć w bezpieczeństwie cyfrowym).

Chociaż prawdą jest, że zaszyfrowanie hasła może być skuteczne w przypadku ujawnienia hasła , jest ono podatne na ataki typu powtórka, ataki typu man-in-the-Middle / porwania (jeśli atakujący może wstrzyknąć kilka bajtów do niezabezpieczonej strony HTML, zanim dotrze ona do twojego przeglądarki, mogą po prostu skomentować skrót w JavaScript) lub ataki typu brute-force (ponieważ przekazujesz atakującemu zarówno nazwę użytkownika, sól, jak i hashowane hasło).

CAPTCHAS przeciwko ludzkości

CAPTCHA ma na celu udaremnienie jednej konkretnej kategorii ataku: automatyczny słownik / brutalna próba i błąd bez udziału operatora. Nie ma wątpliwości, że jest to realne zagrożenie, jednak istnieją sposoby radzenia sobie z nim bezproblemowo, które nie wymagają CAPTCHA, specjalnie odpowiednio zaprojektowanych schematów ograniczania logowania po stronie serwera - omówimy je później.

Wiedz, że implementacje CAPTCHA nie są tworzone podobnie; często nie są one do rozwiązania przez człowieka, większość z nich jest faktycznie nieskuteczna w stosunku do botów, wszystkie z nich są nieskuteczne w stosunku do taniej siły roboczej z trzeciego świata (według OWASP , obecna stawka potu wynosi 12 USD za 500 testów), a niektóre wdrożenia mogą być technicznie nielegalne w niektórych krajach (patrz Arkusz danych uwierzytelniających OWASP ). Jeśli musisz użyć CAPTCHA, skorzystaj z Google reCAPTCHA , ponieważ z definicji jest on trudny do OCR (ponieważ używa już sklasyfikowanych skanów książek z błędem OCR) i bardzo stara się być przyjazny dla użytkownika.

Osobiście uważam, że CAPTCHAS jest denerwujący i używam ich tylko w ostateczności, gdy użytkownik nie zaloguje się wiele razy, a opóźnienia w dławieniu są maksymalne. Zdarzy się to rzadko, aby było możliwe do zaakceptowania i wzmacnia system jako całość.

Przechowywanie haseł / Weryfikowanie logowania

Może to wreszcie być powszechna wiedza po wszystkich szeroko rozpowszechnionych włamaniach i wyciekach danych użytkowników, które widzieliśmy w ostatnich latach, ale trzeba powiedzieć: nie przechowuj haseł w postaci jawnego tekstu w swojej bazie danych. Bazy danych użytkowników są rutynowo hakowane, wyciekane lub zbierane za pomocą wstrzykiwania SQL, a jeśli przechowujesz surowe hasła w postaci jawnego tekstu, jest to natychmiastowa gra dla twojego bezpieczeństwa logowania.

Więc jeśli nie możesz zapisać hasła, jak sprawdzić, czy kombinacja login + hasło POSTed z formularza logowania jest poprawna? Odpowiedź jest mieszana za pomocą funkcji wyprowadzania klucza . Za każdym razem, gdy tworzony jest nowy użytkownik lub hasło jest zmieniane, bierzesz hasło i uruchamiasz je przez KDF, takie jak Argon2, bcrypt, scrypt lub PBKDF2, zamieniając hasło w postaci czystego tekstu („correcthorsebatterystaple”) w długi, losowo wyglądający ciąg , który jest znacznie bezpieczniejszy do przechowywania w bazie danych. Aby zweryfikować login, uruchamiasz tę samą funkcję skrótu na wprowadzonym haśle, tym razem przekazując sól i porównując wynikowy ciąg skrótu z wartością przechowywaną w bazie danych. Argon2, bcrypt i scrypt przechowują sól z hashem już. Więcej informacji znajdziesz w tym artykule na temat sec.stackexchange.

Powodem użycia soli jest to, że hasz sam w sobie nie jest wystarczający - będziesz chciał dodać tak zwaną „sól”, aby zabezpieczyć hash przed tęczowymi stołami . Sól skutecznie zapobiega przechowywaniu dwóch dokładnie pasujących haseł jako tej samej wartości skrótu, zapobiegając skanowaniu całej bazy danych za jednym razem, jeśli atakujący wykonuje atak polegający na zgadywaniu hasła.

Hasła kryptograficznego nie należy używać do przechowywania haseł, ponieważ hasła wybrane przez użytkownika nie są wystarczająco silne (tj. Zwykle nie zawierają wystarczającej entropii), a atak zgadywania hasła może zostać przeprowadzony w stosunkowo krótkim czasie przez atakującego z dostępem do skrótów. Właśnie dlatego stosowane są KDF - te skutecznie „rozciągają klucz” , co oznacza, że ​​każde odgadnięcie hasła przez atakującego powoduje wielokrotne powtórzenie algorytmu skrótu, na przykład 10 000 razy, co powoduje, że atakujący odgaduje hasło 10 000 razy wolniej.

Dane sesji - „Jesteś zalogowany jako Spiderman69”

Gdy serwer zweryfikuje login i hasło w bazie danych użytkowników i znajdzie dopasowanie, system potrzebuje sposobu na zapamiętanie, że przeglądarka została uwierzytelniona. Ten fakt powinien być zawsze przechowywany po stronie serwera w danych sesji.

Jeśli nie znasz danych sesji, oto jak to działa: pojedynczy losowo wygenerowany ciąg jest przechowywany w wygasającym pliku cookie i służy do odwoływania się do zbioru danych - danych sesji - przechowywanych na serwerze. Jeśli używasz frameworka MVC, jest to niewątpliwie już obsługiwane.

Jeśli to w ogóle możliwe, upewnij się, że sesyjny plik cookie ma ustawione flagi bezpieczeństwa i HTTP Only podczas wysyłania do przeglądarki. Flaga HttpOnly zapewnia pewną ochronę przed odczytaniem pliku cookie podczas ataku XSS. Flaga bezpieczeństwa zapewnia, że ​​plik cookie jest wysyłany z powrotem tylko przez HTTPS, a zatem chroni przed atakami podsłuchiwania sieci. Wartość pliku cookie nie powinna być przewidywalna. W przypadku przedstawienia pliku cookie odnoszącego się do nieistniejącej sesji jego wartość należy natychmiast zastąpić, aby zapobiec utrwaleniu sesji .

CZĘŚĆ II: Jak pozostać zalogowanym - Niesławne pole wyboru „Pamiętaj mnie”

Pliki cookie trwałego logowania (funkcja „zapamiętaj mnie”) są strefą niebezpieczną; z jednej strony są one całkowicie tak bezpieczne, jak zwykłe logowanie, gdy użytkownicy rozumieją, jak sobie z nimi radzić; z drugiej strony stanowią ogromne zagrożenie bezpieczeństwa w rękach nieostrożnych użytkowników, którzy mogą z nich korzystać na komputerach publicznych i zapomnieć się wylogować, a którzy mogą nie wiedzieć, jakie są pliki cookie przeglądarki i jak je usunąć.

Osobiście lubię trwałe logowanie do stron, które odwiedzam regularnie, ale wiem, jak sobie z nimi bezpiecznie radzić. Jeśli masz pewność, że użytkownicy wiedzą to samo, możesz korzystać z trwałych loginów z czystym sumieniem. Jeśli nie - cóż, możesz zaakceptować filozofię, że użytkownicy, którzy nieostrożnie podają swoje dane logowania, narzucą to sobie, jeśli zostaną zhakowani. To nie jest tak, że idziemy do domów naszych użytkowników i odrywamy wszystkie te nakręcane przez twarz notatki Post-It hasłami, które ustawili na krawędziach swoich monitorów.

Oczywiście, niektóre systemy nie mogą sobie pozwolić na jakiekolwiek kont hacked; w przypadku takich systemów nie można usprawiedliwić trwałego logowania.

Jeśli zdecydujesz się wdrożyć trwałe pliki cookie do logowania, możesz to zrobić w następujący sposób:

1. Najpierw poświęć trochę czasu na przeczytanie artykułu Paragon Initiative na ten temat. Musisz odpowiednio dobrać kilka elementów, a artykuł objaśnia każdy z nich.

2. I aby powtórzyć jedną z najczęstszych pułapek, NIE PRZECHOWYWAJ TRWAŁEGO LOGOWANIA COOKIE (TOKEN) W SWOJEJ BAZY DANYCH, TYLKO SKRZYDŁO! Token logowania jest równoważny hasłem, więc jeśli osoba atakująca wpadnie na twoją bazę danych, może użyć tokenów do zalogowania się na dowolnym koncie, tak jak gdyby były to jednoznaczne kombinacje hasła do logowania. Dlatego używaj skrótu (zgodnie z https://security.stackexchange.com/a/63438/5002 do tego celu wystarczy słaby skrót) do przechowywania trwałych tokenów logowania.

CZĘŚĆ III: Używanie tajnych pytań

Nie wdrażaj „tajnych pytań” . Funkcja „tajnych pytań” stanowi anty-wzór bezpieczeństwa. Przeczytaj artykuł z linku nr 4 z listy MUST-READ. Możesz zapytać o nią Sarah Palin, po niej Yahoo! konto e-mail zostało zhakowane podczas poprzedniej kampanii prezydenckiej, ponieważ odpowiedź na jej pytanie ochronne brzmiała ... „Wasilla High School”!

Nawet w przypadku pytań określonych przez użytkownika jest wysoce prawdopodobne, że większość użytkowników wybierze:

• „Standardowe” tajne pytanie, takie jak nazwisko panieńskie matki lub ulubione zwierzę domowe

• Prosta ciekawostka, którą każdy może podnieść ze swojego bloga, profilu LinkedIn lub podobnego

• Na każde pytanie, na które łatwiej odpowiedzieć, niż odgadnięcie hasła. Które, dla każdego porządnego hasła, jest każdym pytaniem, jakie możesz sobie wyobrazić

Podsumowując, pytania bezpieczeństwa są z natury niepewne praktycznie we wszystkich ich formach i odmianach i nie powinny być stosowane w systemie uwierzytelniania z jakiegokolwiek powodu.

Prawdziwym powodem, dla którego pytania bezpieczeństwa istnieją nawet na wolności, jest to, że w wygodny sposób oszczędzają na kosztach kilku połączeń z pomocą techniczną od użytkowników, którzy nie mogą uzyskać dostępu do poczty e-mail w celu uzyskania kodu reaktywacyjnego. To kosztem bezpieczeństwa i reputacji Sarah Palin. Warto było? Prawdopodobnie nie.

CZĘŚĆ IV: Funkcjonalność zapomnianego hasła

Wspomniałem już, dlaczego nigdy nie należy używać pytań bezpieczeństwa do obsługi zapomnianych / utraconych haseł użytkowników; oczywiste jest również, że nigdy nie należy wysyłać użytkownikom wiadomości e-mail z ich rzeczywistymi hasłami. W tej dziedzinie są jeszcze co najmniej dwa zbyt częste pułapki:

1. Nie przestawiaj zapomnianego hasła na automatycznie generowane silne hasło - takie hasła są niezwykle trudne do zapamiętania, co oznacza, że ​​użytkownik musi je zmienić lub zapisać - powiedzmy na jasnożółtym plakacie Post-It na brzegu monitora. Zamiast ustawiać nowe hasło, pozwól użytkownikom od razu wybrać nowe hasło - i tak chcą zrobić. (Wyjątkiem może być sytuacja, gdy użytkownicy powszechnie używają menedżera haseł do przechowywania / zarządzania hasłami, których normalnie nie można zapamiętać bez ich zapisania).

2. Zawsze mieszaj utracony kod / token hasła w bazie danych. PONOWNIE , ten kod jest kolejnym przykładem ekwiwalentu hasła, więc MUSI zostać zakodowany na wypadek, gdyby atakujący dostał się w twoją bazę danych. Gdy zażądasz zgubionego hasła, wyślij kod w postaci zwykłego tekstu na adres e-mail użytkownika, a następnie go zaszyfruj, zapisz skrót w bazie danych - i wyrzuć oryginał . Podobnie jak hasło lub trwały token logowania.

Ostatnia uwaga: zawsze upewnij się, że interfejs do wprowadzania „kodu utraconego hasła” jest co najmniej tak samo bezpieczny jak sam formularz logowania, w przeciwnym razie atakujący po prostu użyje tego, aby uzyskać dostęp. Upewnij się, że generujesz bardzo długie „utracone kody haseł” (na przykład 16 znaków alfanumerycznych z rozróżnianiem wielkości liter) to dobry początek, ale rozważ dodanie takiego samego schematu ograniczania przepustowości, jak w przypadku samego formularza logowania.

CZĘŚĆ V: Sprawdzanie siły hasła

Najpierw przeczytaj ten mały artykuł, aby sprawdzić rzeczywistość: 500 najczęściej używanych haseł

Okej, więc może ta lista nie jest kanoniczną listą najpopularniejszych haseł w dowolnym systemie w dowolnym miejscu , ale jest dobrym wskaźnikiem tego, jak słabo ludzie wybierają swoje hasła, gdy nie ma narzuconych zasad. Ponadto lista wygląda przerażająco blisko domu, gdy porównasz ją z publicznie dostępnymi analizami ostatnio skradzionych haseł.

A zatem: Bez minimalnych wymagań dotyczących siły hasła 2% użytkowników korzysta z jednego z 20 najpopularniejszych haseł. Czyli: jeśli atakujący dostanie tylko 20 prób, 1 na 50 kont w Twojej witrynie będzie można wyłamać.

Udaremnienie tego wymaga obliczenia entropii hasła, a następnie zastosowania progu. Publikacja specjalna Narodowego Instytutu Standardów i Technologii (NIST) 800-63 zawiera zestaw bardzo dobrych sugestii. To, w połączeniu z analizą słownika i układu klawiatury (na przykład „qwertyuiop” jest złym hasłem), może odrzucić 99% wszystkich źle wybranych haseł na poziomie 18 bitów entropii. Proste obliczenie siły hasła i pokazanie miernika siły wizualnej jest dobre, ale niewystarczające. O ile nie zostanie to wymuszone, wielu użytkowników najprawdopodobniej go zignoruje.

A dla odświeżającego spojrzenia na łatwość w obsłudze haseł o wysokim stopniu entropii wysoce zalecane jest użycie hasła Randall Munroe's Password Strength xkcd .

Użyj interfejsu API Troy Hunt's Have I Was Pwned, aby sprawdzić hasła użytkowników względem haseł naruszonych w wyniku publicznego naruszenia bezpieczeństwa danych.

CZĘŚĆ VI: Znacznie więcej - lub: Zapobieganie próbom szybkiego logowania

Najpierw spójrz na liczby: Prędkości odzyskiwania hasła - jak długo hasło będzie aktywne

Jeśli nie masz czasu na przeglądanie tabel w tym łączu, oto ich lista:

1. Złamanie słabego hasła praktycznie nie zajmuje czasu , nawet jeśli złamiesz je za pomocą liczydła

2. Złamanie 9-znakowego hasła alfanumerycznego praktycznie nie zajmuje czasu, jeśli nie rozróżnia wielkich i małych liter

3. Złamanie skomplikowanego, złożonego z symboli i liter i cyfr, wielkich i małych liter hasła nie zajmuje prawie czasu, jeśli ma mniej niż 8 znaków (komputer stacjonarny może przeszukiwać całą przestrzeń klawiszy do 7 znaków w jednym przypadku dni lub nawet godzin)

4. Złamanie nawet 6-znakowego hasła zajęłoby jednak nadmiernie dużo czasu, gdyby ograniczono się do jednej próby na sekundę!

Czego możemy się nauczyć z tych liczb? Cóż, wiele, ale możemy skupić się na najważniejszej części: tym, że zapobieganie dużej liczbie szybkich kolejnych prób logowania (tj. Atak brutalnej siły ) naprawdę nie jest takie trudne. Ale zapobieganie temu nie jest tak proste, jak się wydaje.

Ogólnie rzecz biorąc, masz trzy możliwości, które są skuteczne przeciwko atakom siłowym (i atakom słownikowym, ale ponieważ już stosujesz silną politykę haseł, nie powinno to stanowić problemu) :

• Przedstaw CAPTCHA po N nieudanych próbach (denerwujące jak diabli i często nieskuteczne - ale powtarzam się tutaj)

• Blokowanie kont i wymaganie weryfikacji adresu e-mail po N nieudanych próbach (jest to atak DoS czekający na wystąpienie )

• I wreszcie : ograniczenie przepustowości logowania : to znaczy ustawienie opóźnienia między próbami po N nieudanych próbach (tak, ataki DoS są nadal możliwe, ale przynajmniej są znacznie mniej prawdopodobne i o wiele bardziej skomplikowane).

Najlepsza praktyka nr 1: Krótkie opóźnienie czasowe, które zwiększa się wraz z liczbą nieudanych prób, takich jak:

• 1 nieudana próba = bez opóźnienia
• 2 nieudane próby = 2 sekundy opóźnienia
• 3 nieudane próby = 4 sekundy opóźnienia
• 4 nieudane próby = 8 sekund opóźnienia
• 5 nieudanych prób = 16 sekund opóźnienia
• itp.

DoS atakujący ten schemat byłby bardzo niepraktyczny, ponieważ wynikowy czas blokady jest nieco większy niż suma poprzednich czasów blokady.

Wyjaśnienie: opóźnienie nie jest opóźnieniem przed zwróceniem odpowiedzi do przeglądarki. Przypomina to bardziej przekroczenie limitu czasu lub okres refrakcji, podczas którego próby zalogowania się na określone konto lub z określonego adresu IP nie będą w ogóle akceptowane lub oceniane. Oznacza to, że poprawne poświadczenia nie powrócą po pomyślnym zalogowaniu, a nieprawidłowe poświadczenia nie spowodują zwiększenia opóźnienia.

Najlepsza praktyka nr 2: Średnie opóźnienie, które obowiązuje po N nieudanych próbach, takie jak:

• 1-4 nieudane próby = bez opóźnienia
• 5 nieudanych prób = 15-30 min opóźnienia

DoS atakujący ten schemat byłby niepraktyczny, ale z pewnością wykonalny. Warto również zauważyć, że tak duże opóźnienie może być bardzo denerwujące dla legalnego użytkownika. Zapomniani użytkownicy nie będą cię lubić.

Najlepsza praktyka nr 3: Łączenie dwóch podejść - albo stałego, krótkiego opóźnienia, które zaczyna obowiązywać po N nieudanych próbach, takich jak:

• 1-4 nieudane próby = bez opóźnienia
• 5+ nieudanych prób = 20 sekund opóźnienia

Lub rosnące opóźnienie ze stałą górną granicą, takie jak:

• 1 nieudana próba = 5 sekund opóźnienia
• 2 nieudane próby = 15 sekund opóźnienia
• 3+ nieudane próby = 45 sekund opóźnienia

Ten ostateczny schemat został zaczerpnięty z sugestii najlepszych praktyk OWASP (link 1 z listy MUST-READ) i powinien być uważany za najlepszą praktykę, nawet jeśli jest to wprawdzie strona ograniczająca.

Zasadniczo jednak powiedziałbym: im silniejsza jest twoja polityka dotycząca haseł, tym mniej musisz opóźniać użytkowników. Jeśli potrzebujesz silnych (rozróżniających wielkość liter alfanumerycznych + wymaganych cyfr i symboli) 9+ haseł znaków, możesz dać użytkownikom 2-4 nie opóźnione próby hasła przed aktywowaniem ograniczania przepustowości.

DoS atakujący ten schemat ograniczania końcowego logowania byłby bardzo niepraktyczny. I w ostatecznym rozrachunku zawsze zezwalaj na przechowywanie trwałych (cookie) logowań (i / lub formularza logowania zweryfikowanego przez CAPTCHA), dzięki czemu legalni użytkownicy nie będą nawet opóźnieni podczas trwania ataku . W ten sposób bardzo niepraktyczny atak DoS staje się niezwykle niepraktycznym atakiem.

Ponadto sensowne jest bardziej agresywne ograniczanie liczby kont administracyjnych, ponieważ są to najbardziej atrakcyjne punkty wejścia

CZĘŚĆ VII: Rozproszone ataki brutalnej siły

Nawiasem mówiąc, bardziej zaawansowani atakujący będą próbowali obejść ograniczenie przepustowości logowania poprzez „rozprzestrzenianie swoich działań”:

• Dystrybucja prób w botnecie, aby zapobiec oznaczeniu adresu IP

• Zamiast wybierać jednego użytkownika i wypróbować 50 000 najczęstszych haseł (których nie mogą, z powodu naszego ograniczania przepustowości), wybiorą najczęściej używane hasło i wypróbują je przeciwko 50 000 użytkowników. W ten sposób nie tylko omijają środki podejmowane przy maksymalnych próbach, jak CAPTCHA i ograniczanie logowania, zwiększa się również ich szansa na sukces, ponieważ najpopularniejsze hasło numer 1 jest znacznie bardziej prawdopodobne niż numer 49,995

• Rozmieszczenie żądań logowania dla każdego konta użytkownika, powiedzmy, w odstępie 30 sekund, aby zakraść się pod radarem

W tym przypadku najlepszą praktyką byłoby rejestrowanie liczby nieudanych prób logowania w całym systemie i używanie bieżącej średniej częstotliwości złego logowania w witrynie jako podstawy górnego limitu, który następnie nakładasz na wszystkich użytkowników.

Zbyt abstrakcyjny? Pozwól, że sformułuję:

Załóżmy, że w ciągu ostatnich 3 miesięcy Twoja witryna miała średnio 120 złych logowań dziennie. Korzystając z tego (średnia bieżąca), twój system może ustawić globalny limit na 3-krotność - tj. 360 nieudanych prób w ciągu 24 godzin. Następnie, jeśli łączna liczba nieudanych prób na wszystkich kontach przekroczy tę liczbę w ciągu jednego dnia (lub nawet lepiej, monitoruj przyspieszenie i wyzwalaj na obliczonym progu), aktywuje ograniczanie logowania w całym systemie - co oznacza krótkie opóźnienia dla WSZYSTKICH użytkowników (nadal, z wyjątkiem logowania do plików cookie i / lub tworzenia kopii zapasowych loginów CAPTCHA).

Zadałem też pytanie ze szczegółami i naprawdę dobrą dyskusją na temat tego, jak unikać trudnych pułapek w odpieraniu rozproszonych ataków siłowych

CZĘŚĆ VIII: Uwierzytelnianie dwuskładnikowe i dostawcy uwierzytelnienia

Poświadczenia mogą zostać naruszone, czy to przez exploity, spisywane i zagubione hasła, laptopy ze skradzionymi kluczami, czy użytkownicy wprowadzający dane logowania do stron phishingowych. Loginy można dodatkowo zabezpieczyć za pomocą uwierzytelniania dwuskładnikowego, które wykorzystuje czynniki pozapasmowe, takie jak kody jednorazowe odebrane z połączenia telefonicznego, wiadomości SMS, aplikacji lub klucza sprzętowego. Kilku dostawców oferuje usługi uwierzytelniania dwuskładnikowego.

Uwierzytelnianie można całkowicie przekazać do usługi pojedynczego logowania, w której inny dostawca obsługuje zbieranie poświadczeń. To popycha problem do zaufanej strony trzeciej. Zarówno Google, jak i Twitter zapewniają usługi SSO oparte na standardach, a Facebook zapewnia podobne zastrzeżone rozwiązanie.

NIEZBĘDNE CZYTANIE LINKÓW Informacje o uwierzytelnianiu sieci

1. Przewodnik OWASP do uwierzytelniania / Ściągawka do uwierzytelniania OWASP
2. Dos i zakazy uwierzytelnienia klienta w sieci (bardzo czytelny artykuł badawczy MIT)
3. Wikipedia: plik cookie HTTP
4. Pytania dotyczące wiedzy osobistej w przypadku uwierzytelnienia awaryjnego: pytania bezpieczeństwa w erze Facebooka (bardzo czytelny artykuł badawczy Berkeley)

Ostateczny artykuł

Wysyłanie poświadczeń

Jedynym praktycznym sposobem na bezpieczne przesłanie poświadczeń w 100% jest użycie SSL . Używanie JavaScript do mieszania hasła nie jest bezpieczne. Typowe pułapki związane z haszowaniem haseł po stronie klienta:

• Jeśli połączenie między klientem a serwerem nie jest szyfrowane, wszystko, co robisz, jest podatne na ataki typu man-in-the-middle . Osoba atakująca może zastąpić przychodzący skrypt javascript, aby przerwać mieszanie lub wysłać wszystkie dane uwierzytelniające na swój serwer, może słuchać odpowiedzi klienta i podszyć się pod użytkowników, itd. Itp. SSL z zaufanymi urzędami certyfikacji ma na celu zapobieganie atakom MitM.
• Zaszyfrowane hasło otrzymane przez serwer jest mniej bezpieczne, jeśli nie wykonasz dodatkowej, nadmiarowej pracy na serwerze.

Istnieje inna bezpieczna metoda o nazwie SRP , ale jest opatentowana (chociaż jest licencjonowana bez ograniczeń ) i dostępnych jest kilka dobrych implementacji.

Przechowywanie haseł

Nigdy nie przechowuj haseł jako zwykłego tekstu w bazie danych. Nawet jeśli nie dbasz o bezpieczeństwo swojej witryny. Załóż, że niektórzy z Twoich użytkowników ponownie użyją hasła do swojego konta bankowego online. Tak więc przechowuj zaszyfrowane hasło i wyrzuć oryginał. I upewnij się, że hasło nie jest wyświetlane w dziennikach dostępu lub dziennikach aplikacji. OWASP zaleca stosowanie Argon2 jako pierwszego wyboru dla nowych aplikacji. Jeśli nie jest to dostępne, zamiast tego należy użyć PBKDF2 lub scrypt. I na koniec, jeśli żadne z powyższych nie jest dostępne, użyj bcrypt.

Hashe same w sobie są również niepewne. Na przykład identyczne hasła oznaczają identyczne skróty - dzięki temu tabele wyszukiwania skrótów są skutecznym sposobem łamania wielu haseł jednocześnie. Zamiast tego przechowuj solony skrót. Sól to ciąg dołączany do hasła przed haszowaniem - użyj innej (losowej) soli na użytkownika. Sól jest wartością publiczną, więc możesz przechowywać ją z haszem w bazie danych. Zobacz tutaj, aby uzyskać więcej informacji na ten temat.

Oznacza to, że nie możesz wysłać użytkownikowi zapomnianych haseł (ponieważ masz tylko skrót). Nie resetuj hasła użytkownika, chyba że użytkownik go uwierzytelnił (użytkownicy muszą udowodnić, że są w stanie odczytać wiadomości e-mail wysłane na zapisany (zweryfikowany) adres e-mail).

Pytania bezpieczeństwa

Pytania bezpieczeństwa są niepewne - unikaj ich używania. Dlaczego? Cokolwiek robi pytanie bezpieczeństwa, hasło działa lepiej. Przeczytaj CZĘŚĆ III: Używanie tajnych pytań w @Jens Roland, odpowiedz tutaj na tej wiki.

Ciasteczka sesyjne

Po zalogowaniu się, serwer wysyła mu sesyjny plik cookie. Serwer może pobrać nazwę użytkownika lub identyfikator z pliku cookie, ale nikt inny nie może wygenerować takiego pliku cookie (mechanizmy wyjaśniające TODO).

Pliki cookie można przejąć : są one tak bezpieczne, jak reszta komputera klienta i inna komunikacja. Mogą być odczytywane z dysku, wąchane w ruchu sieciowym, podnoszone przez atak skryptowy między witrynami, wyłudzane z zatrutego DNS, więc klient wysyła swoje pliki cookie na złe serwery. Nie wysyłaj trwałych plików cookie. Pliki cookie powinny wygasać pod koniec sesji klienta (przeglądarka zamknie lub opuści domenę).

Jeśli chcesz autologować użytkowników, możesz ustawić trwały plik cookie, ale powinien on różnić się od pliku cookie z pełną sesją. Możesz ustawić dodatkową flagę, że użytkownik zalogował się automatycznie i musi się zalogować, aby wykonać prawdziwe operacje wrażliwe. Jest to popularne w witrynach zakupowych, które chcą zapewnić Ci płynne, spersonalizowane zakupy, ale jednocześnie chronić Twoje dane finansowe. Na przykład po powrocie do witryny Amazon wyświetlana jest strona wyglądająca na zalogowaną, ale po złożeniu zamówienia (lub zmianie adresu wysyłki, karty kredytowej itp.) Użytkownik prosi o potwierdzenie Twoje hasło.

Z drugiej strony witryny finansowe, takie jak banki i karty kredytowe, zawierają tylko poufne dane i nie powinny umożliwiać automatycznego logowania ani trybu niskiego bezpieczeństwa.

Lista zasobów zewnętrznych

• Dos i minusy uwierzytelnienia klienta w sieci (PDF)
  21-stronicowy artykuł akademicki z wieloma świetnymi wskazówkami.
• Zapytaj YC: Najlepsze praktyki dotyczące
  forum uwierzytelniania użytkowników na ten temat
• Prawdopodobnie przechowujesz hasła niepoprawnie
  Artykuł wprowadzający na temat przechowywania haseł
• Dyskusja: Coding Horror: Prawdopodobnie przechowujesz hasła niepoprawnie
  Dyskusja na forum na temat artykułu o Coding Horror.
• Nigdy nie przechowuj haseł w bazie danych!
  Kolejne ostrzeżenie o przechowywaniu haseł w bazie danych.
• Łamanie haseł
  Artykuł w Wikipedii na temat słabości kilku schematów mieszania haseł.
• Wystarczy Tęczowe tablice: Co musisz wiedzieć o bezpiecznych schematach haseł
  Dyskusja na temat tęczowych tabel i jak się przed nimi bronić oraz przed innymi wątkami. Obejmuje obszerną dyskusję.

Po pierwsze, silne zastrzeżenie, że ta odpowiedź nie najlepiej pasuje do tego właśnie pytania. To zdecydowanie nie powinna być najlepsza odpowiedź!

Będę mówić o zaproponowanym przez Mozillę BrowserID (a ściślej Verified Email Protocol ) w duchu znalezienia ścieżki aktualizacji do lepszych podejść do uwierzytelniania w przyszłości.

Podsumuję to w ten sposób:

1. Mozilla jest organizacją non-profit, której wartości dobrze pasują do znalezienia dobrych rozwiązań tego problemu.
2. Obecnie rzeczywistość jest taka, że ​​większość stron internetowych korzysta z uwierzytelniania opartego na formularzu
3. Uwierzytelnianie oparte na formularzu ma dużą wadę, która wiąże się ze zwiększonym ryzykiem phishingu . Użytkownicy proszeni są o podanie poufnych informacji w obszarze kontrolowanym przez zdalny podmiot, a nie w obszarze kontrolowanym przez ich agenta użytkownika (przeglądarkę).
4. Ponieważ przeglądarki są domyślnie zaufane (cała idea Agenta użytkownika polega na działaniu w imieniu użytkownika), mogą pomóc w poprawie tej sytuacji.
5. Główną siłą powstrzymującą postęp tutaj jest impas w rozmieszczeniu . Rozwiązania należy rozłożyć na etapy, które same w sobie przynoszą dodatkowe korzyści.
6. Najprostszą zdecentralizowaną metodą wyrażania tożsamości wbudowanej w infrastrukturę internetową jest nazwa domeny.
7. Jako drugi poziom wyrażania tożsamości każda domena zarządza własnym zestawem kont.
8. Forma „ @domena konta ” jest zwięzła i obsługiwana przez szeroki zakres protokołów i schematów URI. Taki identyfikator jest oczywiście najbardziej powszechnie uznawany za adres e-mail.
9. Dostawcy poczty e-mail są już de facto głównymi dostawcami tożsamości online. Bieżące operacje resetowania hasła zwykle pozwalają przejąć kontrolę nad kontem, jeśli możesz udowodnić, że kontrolujesz powiązany z nim adres e-mail.
10. Zaproponowano zweryfikowany protokół e-mail w celu zapewnienia bezpiecznej metody opartej na kryptografii klucza publicznego w celu usprawnienia procesu udowadniania w domenie B, że masz konto w domenie A.
11. W przypadku przeglądarek, które nie obsługują zweryfikowanego protokołu e-mail (obecnie wszystkie), Mozilla zapewnia podkładkę, która implementuje protokół w kodzie JavaScript po stronie klienta.
12. W przypadku usług e-mail, które nie obsługują Verified Email Protocol, protokół pozwala stronom trzecim działać jako zaufany pośrednik, zapewniając, że zweryfikowali własność konta użytkownika. Nie jest pożądane posiadanie dużej liczby takich stron trzecich; ta funkcja ma na celu jedynie umożliwienie ścieżki uaktualnienia, a usługi e-mailowe same dostarczają te twierdzenia.
13. Mozilla oferuje własne usługi, które działają jak zaufana strona trzecia. Dostawcy usług (tj. Strony ufające) wdrażający zweryfikowany protokół e-mail mogą zaufać twierdzeniom Mozilli lub nie. Usługa Mozilli weryfikuje własność konta użytkowników przy użyciu konwencjonalnych sposobów wysyłania wiadomości e-mail z linkiem potwierdzającym.
14. Usługodawcy mogą oczywiście oferować ten protokół jako opcję oprócz wszelkich innych metod uwierzytelnienia, które chcieliby oferować.
15. Dużą zaletą interfejsu użytkownika jest „selektor tożsamości”. Gdy użytkownik odwiedza witrynę i decyduje się na jej uwierzytelnienie, przeglądarka wyświetla mu wybrane adresy e-mail („osobiste”, „służbowe”, „aktywizm polityczny” itp.), Których mogą użyć do zidentyfikowania się w witrynie.
16. Kolejną dużą zaletą interfejsu użytkownika, której poszukuje się w ramach tego wysiłku, jest pomoc przeglądarce w uzyskaniu więcej informacji na temat sesji użytkownika - przede wszystkim o tym, kto jest zalogowany - aby mógł wyświetlać to w przeglądarce Chrome.
17. Ze względu na rozproszony charakter tego systemu unika on blokowania głównych witryn, takich jak Facebook, Twitter, Google itp. Każda osoba może posiadać własną domenę, a zatem działać jako dostawca tożsamości.

Nie jest to ściśle „uwierzytelnianie oparte na formularzu dla stron internetowych”. Jest to jednak próba przejścia od obecnej normy uwierzytelniania opartego na formularzu do czegoś bardziej bezpiecznego: uwierzytelniania obsługiwanego przez przeglądarkę.

Pomyślałem, że podzielę się tym rozwiązaniem, które okazało się dobrze działać.

Nazywam to Dummy Field (chociaż tego nie wymyśliłem, więc nie wierz mi).

W skrócie: wystarczy wstawić to do swojego <form>i sprawdzić, czy jest pusty przy sprawdzaniu poprawności:

<input type="text" name="email" style="display:none" />

Sztuką jest oszukanie bota, który myśli, że musi wstawić dane do wymaganego pola, dlatego nazwałem wejściowy „email”. Jeśli masz już pole o nazwie e-mail, którego używasz, spróbuj nazwać pole zastępcze czymś innym, na przykład „firma”, „telefon” lub „adres e-mail”. Po prostu wybierz coś, o czym wiesz, że nie potrzebujesz i co brzmi jak coś, co ludzie zwykle uznaliby za logiczne, aby wypełnić formularz internetowy. Teraz ukryj inputpole za pomocą CSS lub JavaScript / jQuery - cokolwiek najbardziej Ci odpowiada - po prostu nie ustawiaj danych wejściowych, typew hiddenprzeciwnym razie bot nie będzie się na to zakochiwał.

Podczas sprawdzania poprawności formularza (po stronie klienta lub serwera) sprawdź, czy pole fikcyjne zostało wypełnione, aby ustalić, czy zostało wysłane przez człowieka czy bota.

Przykład:

W przypadku człowieka: użytkownik nie zobaczy pola zastępczego (w moim przypadku o nazwie „e-mail”) i nie będzie próbował go wypełnić. Tak więc wartość pola fikcyjnego powinna pozostać pusta po wysłaniu formularza.

W przypadku bota: bot zobaczy pole o typie texti nazwie email(lub jakkolwiek go nazwiesz) i logicznie spróbuje wypełnić je odpowiednimi danymi. Nie ma znaczenia, czy stylizowałeś formularz wejściowy za pomocą jakiegoś fantazyjnego CSS, twórcy stron internetowych robią to cały czas. Bez względu na to, jaką wartość ma pole manekina, nie obchodzi nas, dopóki jest on większy niż 0znaki.

Użyłem tej metody w księdze gości w połączeniu z CAPTCHA i od tego czasu nie widziałem ani jednego postu ze spamem. Wcześniej korzystałem z rozwiązania opartego wyłącznie na CAPTCHA, ale ostatecznie powodowało to około pięciu postów spamowych na godzinę. Dodanie pola fikcyjnego do formularza zatrzymało (przynajmniej do tej pory) cały spam.

Uważam, że można to również dobrze wykorzystać w formularzu logowania / uwierzytelnienia.

Ostrzeżenie : Oczywiście ta metoda nie jest w 100% niezawodna. Boty można zaprogramować tak, aby ignorowały pola wprowadzania z display:nonezastosowanym stylem . Musisz także pomyśleć o osobach, które korzystają z jakiejś formy autouzupełniania (jak większość przeglądarek ma wbudowane!), Aby automatycznie wypełnić dla nich wszystkie pola formularza. Równie dobrze mogliby podnieść pole manekina.

Możesz również nieco to zmienić, pozostawiając pole manekina widoczne, ale poza granicami ekranu, ale to zależy od ciebie.

Bądź kreatywny!

Nie sądzę, aby powyższa odpowiedź była „błędna”, ale istnieją duże obszary uwierzytelnienia, które nie zostały poruszone (a raczej nacisk kładziony jest na „jak wdrożyć sesje cookie”, a nie na „jakie opcje są dostępne i jakie są transakcje” -offs ”.

Moje sugerowane zmiany / odpowiedzi to

• Problem leży bardziej w konfiguracji konta niż w sprawdzaniu hasła.
• Korzystanie z uwierzytelniania dwuskładnikowego jest znacznie bezpieczniejsze niż bardziej sprytny sposób szyfrowania hasła

• NIE próbuj wdrażać własnego formularza logowania lub przechowywania bazy danych haseł, chyba że przechowywane dane są bezwartościowe przy tworzeniu konta i generowane przez siebie (to znaczy w stylu Web 2.0, takim jak Facebook, Flickr itp.)

  1. Uwierzytelnianie szyfrowane to podejście oparte na standardach obsługiwane we wszystkich głównych przeglądarkach i serwerach, które nie wyśle ​​hasła nawet za pośrednictwem bezpiecznego kanału.

Pozwala to uniknąć potrzeby posiadania „sesji” lub plików cookie, ponieważ sama przeglądarka za każdym razem ponownie szyfruje komunikację. Jest to najbardziej „lekkie” podejście programistyczne.

Nie polecam tego jednak, z wyjątkiem publicznych usług o niskiej wartości. Jest to problem związany z niektórymi innymi odpowiedziami powyżej - nie próbuj ponownie wdrażać mechanizmów uwierzytelniania po stronie serwera - ten problem został rozwiązany i jest obsługiwany przez większość głównych przeglądarek. Nie używaj plików cookie. Nie przechowuj niczego we własnej, ręcznie zwijanej bazie danych. Zapytaj tylko na żądanie, czy żądanie jest uwierzytelnione. Cała reszta powinna być obsługiwana przez konfigurację i zaufane oprogramowanie innych firm.

Więc ...

Po pierwsze, mylimy początkowe utworzenie konta (z hasłem) z późniejszą weryfikacją hasła. Jeśli jestem Flickr i tworzę witrynę po raz pierwszy, nowy użytkownik ma dostęp do wartości zerowej (pusta przestrzeń internetowa). Naprawdę nie dbam o to, czy osoba tworząca konto kłamie na temat swojego imienia i nazwiska. Jeśli tworzę konto szpitala intranet / extranet, kłamstwa wartości we wszystkich dokumentacji medycznej, a więc zrobić dbają o tożsamości (*) twórcy konta.

To jest bardzo, bardzo trudna część. Tylko przyzwoite rozwiązanie to internetowy zaufania. Na przykład dołączasz do szpitala jako lekarz. Tworzysz stronę internetową hostowaną gdzieś ze swoim zdjęciem, numerem paszportu i kluczem publicznym i łączysz je wszystkie kluczem prywatnym. Następnie odwiedzasz szpital, a administrator systemu patrzy na paszport, sprawdza, czy zdjęcie pasuje do ciebie, a następnie haszy stronę / zdjęcie mieszając klucz prywatny szpitala. Od teraz możemy bezpiecznie wymieniać klucze i tokeny. Jak każdy, kto ufa szpitalowi (istnieje sekretny sos BTW). Administrator systemu może również dać klucz RSA lub inne uwierzytelnianie dwuskładnikowe.

Ale to dużo kłopotów i niezbyt web 2.0. Jest to jednak jedyny bezpieczny sposób na tworzenie nowych kont, które mają dostęp do cennych informacji, które nie są tworzone samodzielnie.

1. Kerberos i SPNEGO - mechanizmy pojedynczego logowania z zaufaną stroną trzecią - w zasadzie użytkownik weryfikuje dane w odniesieniu do zaufanej strony trzeciej. (Uwaga: w żaden sposób nie jest to zaufany OAuth )

2. SRP - rodzaj sprytnego uwierzytelnienia hasła bez zaufanej strony trzeciej. Ale tutaj przechodzimy do dziedziny „bezpieczniej jest używać uwierzytelniania dwuskładnikowego, nawet jeśli jest to bardziej kosztowne”

3. Strona klienta SSL - nadaj klientom certyfikat klucza publicznego (wsparcie we wszystkich głównych przeglądarkach - ale rodzi pytania dotyczące bezpieczeństwa komputera klienckiego).

Ostatecznie jest to kompromis - jaki jest koszt naruszenia bezpieczeństwa w porównaniu z kosztem wdrożenia bardziej bezpiecznych podejść. Pewnego dnia możemy zobaczyć prawidłową powszechnie akceptowaną infrastrukturę PKI, a więc nie będzie już żadnych własnych formularzy uwierzytelniania i baz danych. Pewnego dnia...

Podczas mieszania nie używaj szybkich algorytmów mieszania, takich jak MD5 (istnieje wiele implementacji sprzętowych). Użyj czegoś takiego jak SHA-512. W przypadku haseł wolniejsze skróty są lepsze.

Im szybciej możesz tworzyć skróty, tym szybciej może działać dowolny kontroler brutalnej siły. Wolniejsze skróty spowolnią zatem brutalne wymuszanie. Algorytm powolnego mieszania sprawi, że brutalne wymuszanie dłuższych haseł będzie niepraktyczne (8 cyfr +)

Dobry artykuł na temat realistycznej oceny siły hasła to:

Dropbox Tech Blog »Archiwum blogów» zxcvbn: realistyczne oszacowanie siły hasła

Moja ulubiona zasada dotycząca systemów uwierzytelniania: używaj haseł, a nie haseł. Łatwy do zapamiętania, trudny do złamania. Więcej informacji: Coding Horror: Passwords vs. Pass Phrases

Chciałbym dodać jedną sugestię, której użyłem, opartą na głębokiej obronie. Nie musisz mieć takiego samego systemu uwierzytelniania dla administratorów jak zwykli użytkownicy. Możesz mieć oddzielny formularz logowania na osobnym adresie URL wykonujący osobny kod dla żądań, które przyznają wysokie uprawnienia. To pozwala na dokonywanie wyborów, które byłyby dla zwykłych użytkowników całkowicie uciążliwe. Jednym z takich, których użyłem, jest szyfrowanie adresu URL logowania w celu uzyskania dostępu administratora i przesłanie administratorowi nowego adresu e-mail. Natychmiast zatrzymuje atak brutalnej siły, ponieważ nowy adres URL może być arbitralnie trudny (bardzo długi ciąg losowy), ale jedyną niedogodnością dla administratora jest skorzystanie z łącza w wiadomości e-mail. Atakujący nie wie już, gdzie nawet POST.

Nie wiem, czy najlepiej było odpowiedzieć na to pytanie, czy jako komentarz. Zdecydowałem się na pierwszą opcję.

Jeśli chodzi o poing CZĘŚĆ IV: Funkcja zapomnianego hasła w pierwszej odpowiedzi, chciałbym zwrócić uwagę na ataki czasowe.

W formularzach Zapamiętaj hasło osoba atakująca może potencjalnie sprawdzić pełną listę wiadomości e-mail i wykryć, które są zarejestrowane w systemie (patrz link poniżej).

Jeśli chodzi o formularz zapomnianego hasła, dodam, że dobrym pomysłem jest równe czasy między udanymi i nieudanymi zapytaniami z pewną funkcją opóźnienia.

https://crypto.stanford.edu/~dabo/papers/webtiming.pdf

Chciałbym dodać jeden bardzo ważny komentarz: -

• „W korporacyjnych, intranetowych ustawieniach” większość, jeśli nie wszystkie powyższe, mogą nie mieć zastosowania!

Wiele korporacji wdraża witryny „tylko do użytku wewnętrznego”, które są w rzeczywistości „aplikacjami korporacyjnymi”, które zostały zaimplementowane za pośrednictwem adresów URL. Te adresy URL można (rzekomo ...) rozwiązywać tylko w „wewnętrznej sieci firmy”. (Która sieć magicznie obejmuje wszystkich „wojowników drogowych” związanych z VPN).

Gdy użytkownik jest należycie podłączony do wyżej wymienionej sieci, jego tożsamość („uwierzytelnianie”) jest [już ...] „jednoznacznie znana”, podobnie jak jego pozwolenie („autoryzacja”) na wykonywanie pewnych czynności ... takich jak. .. „aby uzyskać dostęp do tej witryny”.

Ta usługa „uwierzytelniania + autoryzacji” może być świadczona przez kilka różnych technologii, takich jak LDAP (Microsoft OpenDirectory) lub Kerberos.

Z twojego punktu widzenia po prostu wiesz: że każdemu, kto zgodnie z prawem kończy działalność na twojej stronie internetowej, musi towarzyszyć [zmienna środowiskowa magicznie zawierająca ...] „token”. ( tj . brak takiego tokena musi być bezpośrednią podstawą 404 Not Found.)

Wartość tokena nie ma dla ciebie sensu, ale w razie potrzeby istnieją „odpowiednie środki”, za pomocą których witryna może „[autorytatywnie] zapytać kogoś, kto wie (LDAP ... itd.)” O dowolne (!) pytanie, które możesz mieć. Innymi słowy, nie korzystasz z żadnej „domowej logiki”. Zamiast tego pytasz o autorytet i domyślnie ufasz jego werdyktowi.

Uh huh ... to całkiem mentalna zmiana z „dzikiego i wełnianego Internetu”.

Użyj OpenID Connect lub dostępu zarządzanego przez użytkownika .

Ponieważ nic nie jest bardziej wydajne niż w ogóle nie robienie tego.