Pytanie Ostateczny przewodnik po uwierzytelnianiu w oparciu o formularze [zamknięty]


Uwierzytelnianie oparte na formularzach dla stron internetowych

Uważamy, że Stack Overflow nie powinien być po prostu źródłem bardzo szczegółowych pytań technicznych, ale także ogólnych wskazówek, jak rozwiązywać wariacje na temat typowych problemów. "Uwierzytelnianie oparte na formularzach dla stron internetowych" powinno być dobrym tematem do takiego eksperymentu.

Powinien zawierać tematy takie 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
  • Używanie tajnych pytań
  • Zapomniałem nazwy użytkownika / hasła
  • Zastosowanie nonces aby zapobiec żądania fałszowania żądań między witrynami (CSRF)
  • OpenID
  • Pole wyboru "Pamiętaj mnie"
  • Autouzupełnianie nazw użytkowników i haseł
  • Tajne adresy URL (publiczne URL chronione przez trawienie)
  • Sprawdzanie siły hasła
  • Sprawdzanie poczty e-mail
  • i wiele więcej na temat  uwierzytelnianie oparte na formularzu...

Nie powinno to obejmować rzeczy takich jak:

  • Role i autoryzacja
  • Podstawowe uwierzytelnianie HTTP

Pomóż nam:

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

5002


pochodzenie


Dlaczego wyłączyć Uwierzytelnianie podstawowe HTTP? Może pracować w formularzach HTML za pośrednictwem Ajaxa: peej.co.uk/articles/http-auth-with-html-forms.html - system PAUSE
Autentyczne uwierzytelnianie HTTP ma właściwość bycia (względnie) trudnym do zapomnienia przez przeglądarkę. Jest również strasznie niebezpieczna, jeśli nie używasz go z SSL do zabezpieczenia połączenia (tj. HTTPS). - Donal Fellows
Myślę, że warto byłoby rozmawiać o sesjach (w tym fiksacji i porwaniu) ciasteczek (flagi bezpieczne i tylko http) SSO oparte na HTTP - symcbean
Super-użyteczny HttpOnly Flaga cookie, która zapobiega kradzieży plików cookie na podstawie JavaScriptu (podzbiór ataków XSS), również powinna być wymieniona gdzieś. - Alan H.
Łał. Długie odpowiedzi, dziesiątki awansów dla niektórych z nich, ale nikt nie wspomina o częstym błędzie służącym do podawania formularzy logowania przez HTTP. Kłóciłem się nawet z osobami, które powiedziały "ale przechodzi na https: // ..." i dostały tylko puste spojrzenia, gdy zapytałem, czy są pewni, że atakujący nie przepisał niezaszyfrowanej strony, na której podano formularz . - dzuelke


Odpowiedzi:


CZĘŚĆ I: Jak się zalogować

Zakładamy, że już wiesz, jak zbudować formularz HTML logowania i hasła, który POST zwraca wartości do skryptu po stronie serwera w celu uwierzytelnienia. Poniższe sekcje zajmą się wzorcami dla zdrowego auth i jak uniknąć najczęstszych pułapek bezpieczeństwa.

Do HTTPS czy nie do HTTPS?

O ile połączenie nie jest już bezpieczne (czyli tunelowane przez protokół HTTPS przy użyciu protokołu SSL / TLS), wartości formularzy logowania będą wysyłane w postaci zwykłego tekstu, co pozwala każdemu, kto podsłuchuje połączenie między przeglądarką a serwerem sieciowym, będzie mógł odczytać dane logowania podczas ich przekazywania przez. Ten rodzaj podsłuchów jest rutynowo wykonywany przez rządy, ale generalnie nie będziemy zwracać się do "posiadanych" przewodów innych niż to powiedzenie: Jeśli chronisz coś ważnego, użyj HTTPS.

W zasadzie jedyny praktyczny sposób ochrony przed podsłuchem / podsłuchiwanie pakietów podczas logowania odbywa się za pomocą protokołu HTTPS lub innego schematu szyfrowania opartego na certyfikatach (na przykład TLS) lub sprawdzony i przetestowany schemat odpowiedzi na żądanie (na przykład Diffie-Hellmanoparty na SRP). Każda inna metoda może być łatwo ominięta przez podsłuchującego napastnika.

Oczywiście, jeśli chcesz uzyskać nieco niepraktyczne, możesz również zastosować jakąś formę dwuskładnikowego schematu uwierzytelniania (np. Aplikację Google Authenticator, fizyczny zestaw kodów stylu "zimnej wojny" lub klucz klucza generatora RSA). Jeśli zastosowane poprawnie, może to działać nawet z niezabezpieczonym połączeniem, ale trudno sobie wyobrazić, że twórca chciałby zaimplementować dwuskładnikowy mechanizm uwierzytelniania, ale nie SSL.

(Nie) Włóż własne kodowanie / haszowanie JavaScript

Biorąc pod uwagę niezerowe koszty i postrzeganą trudność techniczną związaną z tworzeniem certyfikatu SSL w Twojej witrynie, niektórzy programiści są skłonni wprowadzić własne schematy hashujące lub szyfrujące w przeglądarce, aby uniknąć przekazywania logarytmicznego tekstu jawnego przez niezabezpieczony przewód.

Chociaż jest to szlachetna myśl, jest ona zasadniczo bezużyteczna (i może być luka bezpieczeństwa), chyba że jest połączony z jednym z powyższych - to znaczy zabezpieczeniem linii z silnym szyfrowaniem lub użyciem wypróbowanego i przetestowanego mechanizmu reakcji na żądanie (jeśli nie wiesz, co to jest, po prostu wiedz, że jest to najtrudniej udowodnić, najtrudniej zaprojektować i najtrudniej zrealizować koncepcje w dziedzinie bezpieczeństwa cyfrowego).

Chociaż to prawda, że ​​hashowanie hasłem może być skuteczne przeciwko ujawnienie hasła, jest podatny na powtórne ataki, ataki typu Man-In-the-Middle / porwania (jeśli atakujący może wstrzyknąć kilka bajtów na niezabezpieczoną stronę HTML zanim dotrze do przeglądarki, może po prostu skomentować hashowanie w JavaScript), lub brutalne ataki (ponieważ przekazujesz atakującemu zarówno nazwę użytkownika, sól, jak i hashowane hasło).

CAPTCHAS przeciwko ludzkości

CAPTCHAs mają na celu udaremnić jedną konkretną kategorię ataku: zautomatyzowany słownik / brutalna siła próbna i błąd bez operatora człowieka. Nie ma wątpliwości, że jest to realne zagrożenie, jednak istnieją sposoby na bezproblemowe radzenie sobie z nimi, które nie wymagają CAPTCHA, a właściwie odpowiednio zaprojektowane systemy ograniczania logowania na serwerach - omówimy je później.

Wiedz, że implementacje CAPTCHA nie są tworzone w podobny sposób; często nie są rozwiązaniami ludzkimi, większość z nich jest faktycznie nieskuteczna w stosunku do botów, wszystkie są nieskuteczne w stosunku do taniej pracy trzeciego świata (zgodnie z OWASP, obecna stawka na sweatshop wynosi 12 USD za 500 testów), a niektóre implementacje mogą być technicznie nielegalne w niektórych krajach (zob Arkusz oszustw uwierzytelnienia OWASP). Jeśli musisz użyć CAPTCHA, użyj Google reCAPTCHA, ponieważ jest z definicji twardo-rozpoznawalny (ponieważ używa już sklasyfikowanych w OCR skanów książek) i bardzo stara się być przyjazny dla użytkownika.

Osobiście uważam, że CAPTCHAS jest denerwujący i używa ich tylko w ostateczności, gdy użytkownik nie zalogował się kilka razy, a opóźnienia w przepustnicach są maksymalizowane. Zdarza się to rzadko, aby być akceptowalnym i wzmacnia system jako całość.

Przechowywanie haseł / Weryfikowanie logowania

Może to być ostatecznie powszechna wiedza po wszystkich nagłaśnianych hakach i wyciekach danych użytkownika, które widzieliśmy w ostatnich latach, ale trzeba powiedzieć: nie przechowuj haseł w postaci zwykłego tekstu w bazie danych. Bazy danych użytkowników są rutynowo atakowane przez hakerów, wycieki lub zbierane przez SQL injection, a jeśli przechowujesz surowe, jawne hasła, to natychmiastowe przejście do twojego bezpieczeństwa logowania.

Więc jeśli nie możesz zapisać hasła, w jaki sposób sprawdzasz, czy kombinacja logowania i hasła POSTed z formularza logowania jest poprawna? Odpowiedzią jest mieszanie przy użyciu funkcja wyprowadzania klucza. Za każdym razem, gdy tworzony jest nowy użytkownik lub zmienia się hasło, bierzesz hasło i uruchamiasz je poprzez KDF, takie jak Argon2, bcrypt, scrypt lub PBKDF2, zamieniając tekst jawny ("correcthorsebatterystaple") na długi, losowo wyglądający ciąg , co jest o wiele bezpieczniejsze do przechowywania w bazie danych. Aby zweryfikować logowanie, uruchamiasz tę samą funkcję skrótu dla wprowadzonego hasła, tym razem przekazując sól i porównując wynikowy ciąg hash z wartością przechowywaną w bazie danych. Argon2, bcrypt i scrypt przechowują sól z hashem już. Sprawdź to artykuł na sec.stackexchange w celu uzyskania bardziej szczegółowych informacji.

Powodem użycia soli jest to, że mieszanie samo w sobie nie jest wystarczające - będziesz chciał dodać tak zwaną "sól", aby zabezpieczyć hash przed tabele tęczowe. Sól skutecznie zapobiega przechowywaniu dwóch haseł, które są dokładnie takie same, jak ta sama wartość skrótu, uniemożliwiając skanowanie całej bazy danych w jednym przebiegu, jeśli atakujący wykonuje atak odgadnięcia hasła.

Kryptograficznego skrótu nie należy używać do przechowywania haseł, ponieważ wybrane przez użytkownika hasła nie są wystarczająco silne (tj. Zazwyczaj nie zawierają wystarczającej entropii), a atak polegający na zgadywaniu haseł może zostać zakończony w stosunkowo krótkim czasie przez atakującego z dostępem do skrótów. Właśnie dlatego stosuje się KDF - to skutecznie "rozciągnij klucz" Oznacza to, że każde hasło, które może odgadnąć osoba atakująca, polega na wielokrotnym iterowaniu algorytmu mieszającego, na przykład 10 000 razy, co powoduje, że hasło atakującego zgaduje 10 000 razy wolniej.

Dane sesji - "Jesteś zalogowany jako Spiderman69"

Po zweryfikowaniu przez serwer loginu i hasła w bazie danych użytkownika i znalezieniu dopasowania system musi pamiętać, że przeglądarka została uwierzytelniona. Fakt ten powinien być zawsze przechowywany tylko 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 używany do odniesienia do zbioru danych - danych sesji - przechowywanych na serwerze. Jeśli korzystasz ze środowiska MVC, jest to już niewątpliwie obsługiwane.

Jeśli jest to możliwe, upewnij się, że plik cookie sesji ma ustawione bezpieczne i tylko HTTP flagi podczas wysyłania do przeglądarki. Flaga httponly zapewnia pewną ochronę przed odczytywaniem cookie przez atak XSS. Bezpieczna flaga zapewnia, że ​​plik cookie jest wysyłany tylko za pośrednictwem protokołu HTTPS, a zatem chroni przed atakami podsłuchiwania sieci. Wartość pliku cookie nie powinna być przewidywalna. W przypadku, gdy prezentowane jest ciasteczko odwołujące się do nieistniejącej sesji, jego wartość należy natychmiast wymienić, aby zapobiec utrwalanie sesji.

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

Trwałe pliki cookie logowania (funkcja "zapamiętaj mnie") to strefa niebezpieczna; z jednej strony są one całkowicie bezpieczne, podobnie jak tradycyjne loginy, gdy użytkownicy rozumieją, jak sobie z nimi radzić; az drugiej strony stanowią ogromne zagrożenie dla bezpieczeństwa w rękach nieostrożnych użytkowników, którzy mogą używać ich na publicznych komputerach i zapomnieć się wylogować, a także mogą nie wiedzieć, jakie pliki cookie przeglądarki są lub jak je usunąć.

Osobiście lubię trwałe loginy dla odwiedzanych stron internetowych regularnie, ale wiem, jak sobie z nimi radzić bezpiecznie. Jeśli masz pewność, że użytkownicy wiedzą to samo, możesz używać trwałych loginów z czystym sumieniem. Jeśli nie - cóż, możesz zasubskrybować filozofię, że użytkownicy, którzy są nieostrożni z ich danymi logowania, sprowadzili to na siebie, jeśli zostaną zhakowani. To nie tak, że chodzimy do domów naszych użytkowników i odrywamy wszystkie te notki z postepisem, które wywołują facepalm, z hasłami, które ustawiły na krawędzi monitorów.

Oczywiście niektóre systemy nie mogą sobie pozwolić każdy konta zhackowane; w przypadku takich systemów nie ma możliwości uzasadnienia posiadania trwałych danych logowania.

Jeśli zdecydujesz się wdrożyć trwałe pliki cookie do logowania, oto jak to zrobić:

  1. Najpierw poświęć trochę czasu na przeczytanie Artykuł Paragon Initiative w temacie. Będziesz potrzebował kilku poprawnych elementów, a artykuł świetnie się wyjaśni.

  2. I powtórzyć jedną z najczęstszych pułapek, NIE PRZECHOWUJ PERSISTYCZNEGO COOKIE LOGOWANIA (TOKENU) W TWOJEJ BAZY DANYCH, TYLKO W HASH! Token logowania to Password Equivalent, więc jeśli atakujący dostał się do bazy danych, mógł użyć tokenów do zalogowania się na dowolne konto, tak jakby były kombinacjami login-hasło w postaci zwykłego tekstu. Dlatego używaj mieszania (według https://security.stackexchange.com/a/63438/5002 słaby skrót będzie wystarczający do tego celu) podczas przechowywania trwałych tokenów logowania.

CZĘŚĆ III: Korzystanie z tajnych pytań

Nie wdrażaj "tajnych pytań". Funkcja "tajne pytania" to anty-wzór bezpieczeństwa. Przeczytaj artykuł z linku nr 4 z listy MUST-READ. Możesz zapytać o to Sarah Palin, po jej Yahoo! konto e-mail zostało zhakowane podczas poprzedniej kampanii prezydenckiej, ponieważ odpowiedzią na jej pytanie bezpieczeństwa było ... "Wasilla High School"!

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

  • "Standardowe" tajne pytanie, takie jak imię panieńskie matki lub ulubione zwierzątko

  • Prosty kawałek ciekawostek, który każdy może wyciągnąć ze swojego bloga, profilu LinkedIn lub podobnego

  • Każde pytanie, na które łatwiej odpowiedzieć niż zgadywanie hasła. Dla każdego przyzwoitego hasła każde pytanie można sobie wyobrazić

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

Prawdziwym powodem, dla którego kwestie bezpieczeństwa istnieją nawet w środowisku naturalnym, jest to, że wygodnie oszczędzają one koszt kilku wywołań pomocy technicznej od użytkowników, którzy nie mogą uzyskać dostępu do swoich wiadomości e-mail, aby uzyskać kod reaktywacji. Stało się to kosztem bezpieczeństwa i reputacji Sarah Palin. Warto było? Prawdopodobnie nie.

CZĘŚĆ IV: Funkcja zapomnianego hasła

Już wspomniałem, dlaczego powinieneś nigdy nie używaj pytań bezpieczeństwado obsługi zapomnianych / zagubionych haseł użytkownika; nie trzeba też dodawać, że nigdy nie należy wysyłać użytkownikom e-maili rzeczywistych haseł. Istnieją co najmniej dwa zbyt ogólne pułapki, których należy unikać w tej dziedzinie:

  1. Nie rób tego nastawić zapomniane hasło do autogenerowanego silnego hasła - takie hasła są notorycznie trudne do zapamiętania, co oznacza, że ​​użytkownik musi je zmienić lub zapisać - powiedzmy, na jasnożółtym post-it na skraju monitora. Zamiast ustawiać nowe hasło, pozwól użytkownikom od razu wybrać nowy - i tak właśnie chcą robić. (Wyjątkiem może być sytuacja, w której użytkownicy powszechnie używają menedżera haseł do przechowywania / zarządzania hasłami, których normalnie nie da się zapamiętać bez ich zapisania).

  2. Zawsze mieszaj zagubiony kod hasła / tokena w bazie danych. JESZCZE RAZten kod jest kolejnym przykładem równoważnika hasła, więc MUSI zostać zaszyfrowany w przypadku, gdy atakujący dostał się do bazy danych. Gdy zażąda się zgubionego kodu hasła, wyślij kod w postaci zwykłego tekstu na adres e-mail użytkownika, a następnie wpisz go, zapisz hasz w bazie danych - i wyrzuć oryginał. Podobnie jak hasło lub stały token logowania.

Ostatnia uwaga: zawsze upewnij się, że twój interfejs do wpisania "kodu zagubionego hasła" jest co najmniej tak samo bezpieczny jak twój formularz logowania, lub atakujący po prostu użyje tego, by uzyskać dostęp. Upewnienie się, że generujesz bardzo długie "zagubione hasła" (na przykład 16 znaków alfanumerycznych) jest dobrym początkiem, ale rozważ dodanie tego samego schematu dławienia, który robisz dla samego formularza logowania.

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

Najpierw będziesz chciał przeczytać ten mały artykuł do sprawdzenia rzeczywistości: 500 najczęściej używanych haseł

Okay, więc może lista nie jest tą kanoniczny lista najczęściej używanych haseł każdy system kiedykolwiek w życiu, ale to dobra wskazówka, jak kiepsko ludzie będą wybierać swoje hasła, gdy nie ma obowiązujących zasad. Co więcej, lista wygląda przerażająco blisko domu, kiedy porównasz ją z publicznie dostępnymi analizami ostatnio skradzionych haseł.

Tak więc: bez minimalnych wymagań dotyczących siły hasła, 2% użytkowników używa jednego z 20 najpopularniejszych haseł. Znaczenie: jeśli atakujący uzyska tylko 20 prób, 1 na 50 kont w Twojej witrynie będzie dostępny do zapisania.

Pokonanie tego wymaga obliczenia entropii hasła, a następnie zastosowania progu. Narodowy Instytut Standardów i Technologii (NIST) Specjalna publikacja 800-63 ma zestaw bardzo dobrych sugestii. To, w połączeniu ze słownikiem i analizą układu klawiatury (na przykład "qwertyuiop" jest złym hasłem), może odrzucić 99% wszystkich źle dobranych haseł na poziomie 18 bitów entropii. Po prostu obliczanie siły hasła i pokazano wizualny miernik siły dla użytkownika jest dobry, ale niewystarczający. O ile nie zostanie to wymuszone, wielu użytkowników najprawdopodobniej zignoruje to.

I dla odświeżającego podejścia do łatwości obsługi haseł o wysokiej entropii, Randall Munroe's Siła hasła xkcd jest wysoce zalecane.

CZĘŚĆ VI: O wiele więcej - lub: Zapobieganie próbom logowania w trybie natychmiastowym

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

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

  1. To trwa praktycznie nie ma czasu złamać słabe hasło, nawet jeśli używasz liczydła

  2. To trwa praktycznie nie ma czasu złamać alfanumeryczne 9-znakowe hasło, jeśli tak jest bez względu na wielkość liter

  3. To trwa praktycznie nie ma czasu łamać skomplikowane, symbole-i-litery-i-liczby, wielkie i małe litery, jeśli tak jest mniej niż 8 znaków (komputer stacjonarny może przeszukać cały obszar kluczy do 7 znaków w ciągu kilku dni lub nawet godzin)

  4. Zajmie to jednak zbyt wiele czasu, aby złamać nawet 6-znakowe hasło, gdybyś był ograniczony do jednej próby na sekundę!

Czego możemy się nauczyć z tych liczb? Cóż, dużo, ale możemy skupić się na najważniejszej części: na tym, że zapobieganie dużej liczbie szybkich po sobie kolejnych prób logowania (np. brutalna siła atak) naprawdę nie jest takie trudne. Ale zapobieganie temu dobrze nie jest tak proste, jak się wydaje.

Ogólnie mówiąc, masz trzy możliwości, które są skuteczne w walce z brutalnymi atakami (i ataki słownikowe, ale ponieważ już stosujesz zasady silnych haseł, nie powinny być problemem):

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

  • Blokowanie kont i wymaganie weryfikacji adresu e-mail po N nieudanych próbach (to jest DoS atak czeka)

  • I w końcu, dławienie logowania: to jest ustawienie czasu opóźnienia między próbami po N nieudanych próbach (tak, ataki DoS są nadal możliwe, ale przynajmniej są o wiele mniej prawdopodobne i dużo bardziej skomplikowane do ściągnięcia).

Najlepsza praktyka nr 1: Krótkie opóźnienie zwiększające się wraz z liczbą nieudanych prób, na przykład:

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

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

Aby wyjaśnić: Opóźnienie to nie opóźnienie przed zwróceniem odpowiedzi do przeglądarki. Przypomina to raczej czas oczekiwania lub okres refrakcji, w którym próba zalogowania się na określone konto lub z określonego adresu IP nie zostanie w ogóle zaakceptowana lub oceniona. Oznacza to, że prawidłowe dane logowania nie powrócą w wyniku pomyślnego logowania, a nieprawidłowe dane uwierzytelniające nie spowodują zwiększenia opóźnienia.

Najlepsza praktyka nr 2: Średniej długości opóźnienie, które wchodzi w życie po N nieudanych próbach, takich jak:

  • 1-4 nieudanych prób = brak opóźnienia
  • 5 nieudanych prób = opóźnienie 15-30 minut

DoS atakujący ten schemat byłby całkiem niepraktyczny, ale na pewno wykonalny. Warto również zauważyć, że takie długie opóźnienie może być bardzo denerwujące dla prawowitego użytkownika. Zapominali Cię nieprzygotowani użytkownicy.

Najlepsza praktyka nr 3: Połączenie obu podejść - stałe, krótkie opóźnienie, które wchodzi w życie po N nieudanych próbach, takich jak:

  • 1-4 nieudanych prób = brak opóźnienia
  • 5+ nieudanych prób = opóźnienie 20 sekund

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

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

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

Zasadniczo jednak powiedziałbym: im silniejsza jest twoja polityka haseł, tym mniej musisz martwić użytkowników opóźnieniami. Jeśli potrzebujesz silnego (alfanumeryczny z rozróżnianiem wielkości liter + wymagane cyfry i symbole) Ponad 9 znaków hasła, możesz dać użytkownikom 2-4 nieopóźnione próby podania hasła przed aktywacją funkcji dławienia.

DoS atakowałby ten ostateczny schemat dławienia logowania bardzo niepraktyczny. W ostatecznym rozrachunku zawsze zezwalaj na trwałe logowanie (cookie) (i / lub formularz logowania zweryfikowany przez CAPTCHA), aby legalni użytkownicy nie byli nawet opóźnieni gdy atak jest w toku. W ten sposób bardzo niepraktyczny atak DoS staje się niezwykle niepraktyczny atak.

Dodatkowo sensowne jest bardziej agresywne ograniczanie na kontach administracyjnych, ponieważ są to najbardziej atrakcyjne punkty wejścia

CZĘŚĆ VII: Rozproszone ataki siłami brutalnymi

Tak jak na marginesie, bardziej zaawansowani agresorzy będą starali się ominąć ograniczanie logowania poprzez "rozpowszechnianie ich działań":

  • Dystrybucja prób w botnecie w celu zapobieżenia oznaczaniu adresu IP

  • Zamiast wybierać jednego użytkownika i próbować 50 000 najpopularniejszych haseł (których nie mogą, z powodu naszego dławienia), wybiorą najbardziej popularne hasło i spróbują go zamiast 50 000 użytkowników. W ten sposób nie tylko osiągają maksymalne próby takie jak CAPTCHA i ograniczanie logowania, ich szanse na sukces również wzrastają, ponieważ najczęściej używane hasło numer 1 jest znacznie bardziej prawdopodobne niż numer 49.995.

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

Oto najlepsza praktyka rejestrowanie liczby nieudanych logowań, w całym systemiei wykorzystywanie średniej bieżącej złą częstotliwość logowania w witrynie jako podstawy dla górnego limitu, który następnie nakładasz na wszystkich użytkowników.

Zbyt abstrakcyjne? Pozwól mi zmienić:

Załóżmy, że Twoja witryna miała średnio 120 złych logowań dziennie w ciągu ostatnich 3 miesięcy. Używając tej (średniej bieżącej), twój system może ustawić globalny limit na 3-krotny - tj. 360 nieudanych prób w ciągu 24 godzin. Następnie, jeśli całkowita liczba nieudanych prób na wszystkich kontach przekroczy tę liczbę w ciągu jednego dnia (lub nawet lepiej, monitoruj szybkość przyspieszenia i wyzwalacz na wyliczonym progu), aktywuje systemowe ograniczanie logowania - co oznacza krótkie opóźnienia dla WSZYSTKICH użytkowników (nadal, z wyjątkiem loginów i / lub zapasowych loginów CAPTCHA).

Zadałem też pytanie więcej szczegółów i naprawdę dobra dyskusja na temat tego, jak unikać trudnych pułapek w odpieraniu rozproszonych ataków brutalnej siły

CZĘŚĆ VIII: Dostawcy uwierzytelnień i uwierzytelniania dwuetapowego

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

Uwierzytelnienie można całkowicie przekazać do usługi pojedynczego logowania, w której inny dostawca obsługuje gromadzenie danych uwierzytelniających. Powoduje to problem zaufanej stronie trzeciej. Google i Twitter zapewniają usługi SSO oparte na standardach, natomiast Facebook zapewnia podobne zastrzeżone rozwiązanie.

PRZECZYTAJ LINKI O Uwierzytelnieniu w Internecie

  1. OWASP Przewodnik po uwierzytelnianiu / Arkusz oszustw uwierzytelnienia OWASP
  2. Dawkowanie i zakaz uwierzytelniania klienta w sieci (bardzo czytelny dokument badawczy MIT)
  3. Wikipedia: ciasteczko HTTP
  4. Pytania osobiste dotyczące uwierzytelniania awaryjnego: pytania bezpieczeństwa w erze Facebooka (bardzo czytelny dokument badawczy Berkeley)

3498



Cóż, nie zgadzam się z częścią Captcha, tak, że Captchas są irytujące i mogą zostać złamane (z wyjątkiem recaptcha, ale jest to ledwo możliwe do rozwiązania przez ludzi!), Ale to jest dokładnie tak, jak mówienie, nie używaj filtra antyspamowego, ponieważ ma mniej niż 0,1% wyników fałszywie ujemnych .. ta strona używa Captcha, nie są one doskonałe, ale przecinają znaczną ilość spamu i nie ma po prostu dobrej alternatywy dla nich - Waleed Eissa
@Jeff: Przykro mi słyszeć, że masz problemy z moją odpowiedzią. Nie wiedziałem, że w sprawie tej odpowiedzi była debata na temat Meta, chętnie bym ją zredagował, gdybyś mnie o to poprosił. Usunięcie moich wpisów spowodowało usunięcie z mojego konta 1200 punktów reputacji, co boli :( - Jens Roland
"Po wysłaniu tokenów uwierzytelniania, system potrzebuje sposobu na zapamiętanie, że zostałeś uwierzytelniony - ten fakt powinien być zawsze przechowywany tylko w danych sesji, a plik cookie może służyć do odniesienia się do danych sesji." Nie do końca. Możesz (i powinieneś, na serwerach bezpaństwowych!) Korzystać z plików cookie podpisanych kryptograficznie. To niemożliwe do podrobienia, nie wiąże zasobów serwera i nie potrzebuje lepkich sesji lub innych shenaniganów. - Martin Probst
"komputer stacjonarny może przeszukiwać PEŁNĄ KEYSPACE do 7 znaków w mniej niż 90 dni" Maszyna z nowym układem GPU może przeszukać pełny obszar 7 znaków w mniej niż 1 dzień. Najwyższej klasy procesor graficzny może zarządzać 1 miliardem haszy na sekundę. golubev.com/hashgpu.htm  Prowadzi to do pewnych wniosków dotyczących przechowywania haseł, które nie są bezpośrednio adresowane. - Frank Farmer
Jestem zaskoczony, że ochrona CSRF nie została wspomniana ... - Flukey


Artykuł ostateczny

Przesyłanie poświadczeń

Jedynym praktycznym sposobem bezpiecznego wysyłania referencji jest użycie SSL. Używanie JavaScript do haszowania hasła nie jest bezpieczne. Typowe pułapki dla haszowania hasłem po stronie klienta:

  • Jeśli połączenie między klientem a serwerem jest nieszyfrowane, wszystko, co robisz, jest narażone na ataki typu "man-in-the-middle". Osoba atakująca może zastąpić przychodzący javascript w celu przerwania hashowania lub wysłać wszystkie dane uwierzytelniające do swojego serwera, może wysłuchać odpowiedzi klientów i doskonale podszyć się pod użytkowników itp. Itd. SSL z zaufanymi urzędami certyfikacji ma na celu zapobieganie atakom MitM.
  • Hashowane hasło otrzymane przez serwer to Mniej bezpieczne jeśli nie wykonasz dodatkowej, nadmiarowej pracy na serwerze.

Istnieje inna bezpieczna metoda nazywana SRP, ale jest opatentowany (choć tak jest swobodnie licencjonowane) i dostępnych jest niewiele dobrych wdrożeń.

Przechowywanie haseł

Nigdy nie przechowuj haseł jako zwykłego tekstu w bazie danych. Nawet jeśli nie dbasz o bezpieczeństwo swojej strony. Załóżmy, że niektórzy użytkownicy będą ponownie używać hasła do swojego internetowego konta bankowego. Dlatego przechowuj zaszyfrowane hasło i wyrzuć oryginał. Upewnij się też, że hasło nie pojawia się w dziennikach dostępu lub dziennikach aplikacji. OWASP zaleca użycie Argon2 jako pierwszy wybór dla nowych aplikacji. Jeśli nie jest to możliwe, zamiast tego należy użyć PBKDF2 lub scrypt. I na koniec, jeśli żadna z powyższych nie jest dostępna, użyj bcrypt.

Same hashe są również niepewne. Na przykład identyczne hasła oznaczają identyczne hashe - dzięki temu tablice skrótów są skutecznym sposobem na złamanie wielu haseł naraz. Zamiast tego przechowuj posolony haszysz. Sól to ciąg dodawany do hasła przed hashowaniem - użyj innej (losowej) soli na użytkownika. Sól jest wartością publiczną, więc możesz przechowywać je z hashem w bazie danych. Widzieć tutaj więcej informacji na ten temat.

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

Pytania bezpieczeństwa

Pytania bezpieczeństwa są niepewne - unikaj ich używania. Czemu? Wszystko, co robi pytanie bezpieczeństwa, hasło jest lepsze. Czytać CZĘŚĆ III: Korzystanie z tajnych pytań w @Jens Roland odpowiedź tutaj na tej wiki.

Pliki cookie sesji

Po zalogowaniu się użytkownik wysyła ciasteczko sesji. 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 mogą zostać przejęte: są tak bezpieczne, jak reszta maszyny klienta i inna komunikacja. Mogą być odczytywane z dysku, węszone w ruchu sieciowym, podnoszone przez ataki typu cross-site scripting, wyłudzane z zatrutego DNS, więc klient wysyła pliki cookie na niewłaściwe serwery. Nie wysyłaj trwałych plików cookie. Pliki cookie powinny wygasać po zakończeniu sesji klienta (zamknięcie przeglądarki lub opuszczenie domeny).

Jeśli chcesz autologować swoich użytkowników, możesz ustawić stały plik cookie, ale powinien on być inny niż plik cookie w pełnej sesji. Możesz ustawić dodatkową flagę, która został automatycznie zalogowana przez użytkownika, i musisz zalogować się jako prawdziwa dla wrażliwych operacji. Jest to popularne w witrynach sklepów, które chcą zapewnić Ci bezproblemową, spersonalizowaną obsługę zakupów, ale wciąż chronią Twoje dane finansowe. Na przykład, po powrocie do Amazon, wyświetlają się strony, które wyglądają, jakbyś był zalogowany, ale kiedy udasz się złożyć zamówienie (lub zmienić adres wysyłki, kartę kredytową itp.), Poprosi Cię o potwierdzenie Twoje hasło.

Z kolei strony internetowe, takie jak banki i karty kredytowe, mają jedynie poufne dane i nie powinny zezwalać na automatyczne logowanie lub tryb niskiego bezpieczeństwa.

Lista zasobów zewnętrznych


387



Biorąc pod uwagę niedawną lukę MITM wokół podpisanych certyfikatów SSL (blog.startcom.org/?p=145), więc połączenie SSL i pewnego rodzaju uwierzytelnianie w odpowiedzi na wyzwania (istnieją alternatywy dla SRP) jest prawdopodobnie lepszym rozwiązaniem. - Kevin Loney
wiele z tych rzeczy jest sytuacyjnych. W ogóle nie używam ciasteczek sesyjnych. Przechwycenie ciasteczek prawie zawsze oznacza awarię serwerów. człowiek w środku / sniffing pakietów nie są tak powszechne - Shawn
Pakiet BCrypt Nuget: nuget.org/List/Packages/BCrypt - Fabian Vilers
Uwaga 1 na temat tej odpowiedzi: jest to wersja robocza, która ma być edytowana jako wiki. Jeśli możesz to edytować, możesz to zrobić. - Peter Mortensen


Po pierwsze, silne zastrzeżenie, że ta odpowiedź nie jest najlepiej dopasowana do tego dokładnego pytania. To zdecydowanie nie powinna być najlepsza odpowiedź!

Przedstawię propozycję Mozilli BrowserID (a może bardziej precyzyjnie Zweryfikowany protokół e-mail) w duchu znalezienia lepszej ścieżki do lepszego podejścia do uwierzytelniania w przyszłości.

Podsumuję to w ten sposób:

  1. Mozilla jest organizacją non-profit z wartości które dobrze pasują do znalezienia dobrych rozwiązań tego problemu.
  2. Obecnie większość witryn korzysta z uwierzytelniania opartego na formularzach
  3. Uwierzytelnianie oparte na formularzach ma dużą wadę, która wiąże się ze zwiększonym ryzykiem wyłudzanie informacji. Użytkownicy są proszeni o wprowadzenie poufnych informacji do obszaru kontrolowanego przez zdalną jednostkę, a nie do obszaru kontrolowanego przez ich agenta użytkownika (przeglądarkę).
  4. Ponieważ przeglądarki są niejawnie zaufane (cała idea User Agenta ma działać w imieniu Użytkownika), mogą pomóc poprawić tę sytuację.
  5. Główną siłą powstrzymującą tutaj postęp jest impas wdrażania. Rozwiązania muszą zostać rozłożone na etapy, które same przynoszą pewne dodatkowe korzyści.
  6. Najprostszą zdecentralizowaną metodą wyrażania tożsamości wbudowaną 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. Formularz "konto@domena "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 przepływy resetowania hasła pozwalają zwykle przejąć kontrolę nad kontem, jeśli możesz udowodnić, że kontrolujesz powiązany z nim adres e-mail konta.
  10. Zaproponowano, aby zweryfikowany protokół poczty elektronicznej zapewniał bezpieczną metodę, opartą na kryptografii klucza publicznego, w celu usprawnienia procesu sprawdzania w domenie B, że posiadasz konto w domenie A.
  11. W przeglądarkach, które nie obsługują Verified Email Protocol (obecnie wszystkie z nich), 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ą zweryfikowanego protokołu e-mail, protokół pozwala stronom trzecim działać jako zaufany pośrednik, potwierdzając, że zweryfikowały własność konta. Nie jest pożądane posiadanie dużej liczby takich stron trzecich; Ta funkcja jest przeznaczona tylko do umożliwienia ścieżki uaktualnienia i jest bardzo korzystne, aby usługi e-mail same dostarczały te twierdzenia.
  13. Mozilla oferuje własną usługę, aby działać jako zaufana strona trzecia. Dostawcy usług (tj. Strony ufające) wdrażające zweryfikowany protokół poczty elektronicznej mogą zaufać twierdzeniom Mozilli. Usługa Mozilli weryfikuje własność konta użytkownika za pomocą konwencjonalnych sposobów wysyłania wiadomości e-mail z linkiem potwierdzającym.
  14. Dostawcy usług mogą oczywiście oferować ten protokół jako opcję oprócz innych metod uwierzytelniania, które mogą zaoferować.
  15. Dużą zaletą interfejsu użytkownika jest tutaj "selektor tożsamości". Kiedy użytkownik odwiedza witrynę i decyduje się na uwierzytelnienie, przeglądarka pokazuje im wybrane adresy e-mail ("osobiste", "praca", "polityczny aktywizm" itp.), Których mogą użyć do identyfikacji się na stronie.
  16. Innym dużym interfejsem użytkownika jest szukanie w ramach tego wysiłku pomagając przeglądarce dowiedzieć się więcej o sesji użytkownika - kto jest zalogowany jako obecnie, przede wszystkim - może to wyświetlać w chrome przeglądarki.
  17. Ze względu na rozproszony charakter tego systemu, unika się blokowania głównych stron takich jak Facebook, Twitter, Google itd. Każda osoba może posiadać własną domenę, a zatem działać jako własny dostawca tożsamości.

To nie jest ściśle "uwierzytelnianie oparte na formularzach dla stron internetowych". Jest to jednak próba przejścia od obecnej normy uwierzytelniania opartego na formularzach do czegoś bardziej bezpiecznego: uwierzytelnianie obsługiwane przez przeglądarkę.


146



Link do przeglądarki nie działa - Mehdi
Wygląda na to, że projekt został wstrzymany ... zobacz en.wikipedia.org/wiki/Mozilla_Persona - Jeff Olson


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

Ja to nazywam Pole Dummy (chociaż nie wymyśliłem tego, więc nie wierzcie mi).

W skrócie: wystarczy włożyć to do swojego <form> i podczas sprawdzania poprawności sprawdź, czy jest pusty:

<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ście "e-mail". Jeśli masz już pole o nazwie e-mail, którego używasz, spróbuj nazwać pole dummy czymś innym, jak "firma", "telefon" lub "adres e-mail". Po prostu wybierz coś, czego nie potrzebujesz i co brzmi jak coś, co ludzie zwykle logicznie logują do formularza internetowego. Teraz ukryj input pole przy użyciu CSS lub JavaScript / jQuery - cokolwiek pasuje najlepiej - po prostu nie rób tego ustaw wejście type do hidden albo bot nie zakocha się w tym.

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

Przykład:

W przypadku człowieka: Użytkownik nie zobaczy fikcyjnego pola (w moim przypadku jest to "e-mail") i nie będzie próbował go wypełnić. Wartość pola dummy powinna być pusta po wysłaniu formularza.

W przypadku bota: Bot zobaczy pole, którego typ jest text i imię email (lub cokolwiek to nazwał) i logicznie spróbuje wypełnić go odpowiednimi danymi. Nie obchodzi go, czy stylizujesz formularz wejściowy z jakimś wyszukanym CSS, programiści robią to cały czas. Niezależnie od wartości w polu obojętnym, nie obchodzi nas to tak długo, jak długo jest większe niż 0 postacie.

Użyłem tej metody w księdze gości w połączeniu z CAPTCHAi od tego czasu nie widziałem żadnego spamu. Używałem wcześniej rozwiązania typu CAPTCHA, ale w rezultacie co godzinę pojawiało się około pięciu wpisów spamowych. Dodanie pola manekina w formularzu zatrzymało (przynajmniej do tej pory) cały spam, który się pojawił.

Wierzę, że można to również dobrze wykorzystać przy użyciu formularza logowania / uwierzytelnienia.

Ostrzeżenie: Oczywiście ta metoda nie jest w 100% dowodem na głupotę. Boty można zaprogramować tak, aby ignorowały pola wejściowe ze stylem display:none zastosowane do niego. Musisz też pomyśleć o osobach, które korzystają z automatycznego uzupełniania (jak większość wbudowanych przeglądarek!), Aby automatycznie wypełnić dla nich wszystkie pola formularza. Równie dobrze mogą wybrać pole obojętne.

Możesz też nieco to zmienić, pozostawiając widoczne pole obojętne, ale poza granicami ekranu, ale to zależy wyłącznie od Ciebie.

Bądź kreatywny!


120



Jest to przydatna sztuczka antyspamowa, ale sugerowałbym użycie nazwy pola innej niż "e-mail" lub może się okazać, że automatyczne wypełnianie w przeglądarce wypełnia ją, nieumyślnie blokując prawdziwych użytkowników Twojej witryny. - Nico Burns
Mam też kilka więcej z nich korzystających visibility:hidden i również position:absolute;top:-9000px możesz także zrobić text-indent i również z-index na kilka z tych elementów i umieść je w skompresowanych nazwach plików CSS z niezręcznymi nazwami - ponieważ boty mogą wykryć 1display: none` i teraz sprawdzają zakres kombinacji - w rzeczywistości używam tych metod i są to stare sztuczki z handlu . +1 - TheBlackBenzKid
Co się dzieje, gdy użytkownik z zaburzeniami widzenia używa czytnika ekranu do nawigacji po formularzu? - gtcharlie
Ta technika ma nazwę: honeypot en.wikipedia.org/wiki/Honeypot_(computing) - pixeline
Nie ma potrzeby stosowania wbudowanej stylizacji. Wystarczy dodać klasę do pola (może użyć dziwnego słowa, które nigdy nie znaczy nic dla bota) i ukryć go za pomocą pliku CSS witryny. Lubić: <input type="text" name="email" class="cucaracha"> i w twoim CSS: .cucaracha { display:none; }. - Ricardo Zea


Nie sądzę, aby powyższa odpowiedź była "zła", ale istnieją duże obszary uwierzytelniania, które nie są poruszane (a raczej nacisk kładzie się na "jak realizować sesje cookie", a nie na "jakie opcje są dostępne i jakie są transakcje? offs ".

Moje sugerowane zmiany / odpowiedzi są

  • Problem leży bardziej w konfiguracji konta niż w sprawdzaniu hasła.
  • Używanie uwierzytelniania dwuskładnikowego jest o wiele bezpieczniejsze niż mądrzejszy sposób szyfrowania haseł
  • NIE próbuj zaimplementować własnego formularza logowania lub bazy danych haseł, chyba że przechowywane dane są bezwartościowe przy tworzeniu kont i generowane samodzielnie (czyli w stylu Web 2.0, jak Facebook, Flickritp.)

    1. Digest Authentication to podejście oparte na standardach obsługiwane we wszystkich głównych przeglądarkach i serwerach, które nie wysyłają hasła nawet za bezpieczny kanał.

Pozwala to uniknąć konieczności "sesji" lub plików cookie, ponieważ sama przeglądarka zaszy- wa ponownie szyfrowanie komunikacji za każdym razem. Jest to najbardziej "lekkie" podejście programistyczne.

Jednak nie polecam tego, z wyjątkiem publicznych usług o niskiej wartości. Jest to problem 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 ciasteczek. Nie przechowuj niczego w swojej własnej walcowanej bazie danych. Po prostu zapytaj, na żądanie, czy żądanie jest uwierzytelnione. Wszystko inne powinno być wspierane przez konfigurację i zaufane oprogramowanie innych firm.

Więc ...

Po pierwsze mylimy początkowe utworzenie konta (z hasłem) z ponownie sprawdź hasło w późniejszym czasie. Jeśli jestem Flickr i tworzę twoją witrynę po raz pierwszy, nowy użytkownik ma dostęp do zerowej wartości (puste miejsce w sieci). Naprawdę nie obchodzi mnie, czy osoba tworząca konto kłamie na temat swojego nazwiska. Jeśli tworzę konto intranet / extranet szpitala, wartość leży we wszystkich dokumentach medycznych, a więc ja zrobić troszcz się o tożsamość (*) twórcy konta.

To bardzo trudna część. The tylko przyzwoite rozwiązanie to sieć zaufania. Na przykład wstąpisz do szpitala jako lekarz. Tworzysz stronę internetową hostowaną gdzieś ze swoim zdjęciem, numerem paszportu i kluczem publicznym, a następnie mieszając je z kluczem prywatnym. Następnie udajesz się do szpitala i administrator systemu sprawdza twój paszport, widzi, czy zdjęcie pasuje do ciebie, a następnie miesza haszowanie strony internetowej / zdjęcia z prywatnym kluczem szpitala. Od teraz możemy bezpiecznie wymieniać klucze i tokeny. Jak każdy, kto ufa szpitalowi (jest sekretny sos BTW). Administrator systemu może również dać ci RSA dongle lub inne uwierzytelnianie dwuskładnikowe.

Ale to jest los kłopotów, a nie bardzo web 2.0. Jest to jednak jedyny bezpieczny sposób tworzenia nowych kont, które mają dostęp do cennych informacji, które nie są tworzone samodzielnie.

  1. Kerberos i SPNEGO - mechanizmy jednokrotnego logowania z zaufaną stroną trzecią - w zasadzie użytkownik weryfikuje zaufaną stronę trzecią. (Uwaga: w żaden sposób nie można ufać OAuth)

  2. SRP - rodzaj sprytnego uwierzytelniania hasła bez zaufanej strony trzeciej. Ale tutaj wkraczamy w sferę "bezpieczniej jest używać uwierzytelniania dwuskładnikowego, nawet jeśli jest to droższe"

  3. SSL po stronie klienta - nadaj klientom certyfikat klucza publicznego (wsparcie we wszystkich głównych przeglądarkach - ale stawia pytania przed bezpieczeństwem komputera klienckiego).

W końcu jest to kompromis - jaki jest koszt naruszenia bezpieczeństwa w porównaniu do kosztów wdrożenia bardziej bezpiecznego podejścia. Pewnego dnia możemy zobaczyć coś odpowiedniego PKI powszechnie akceptowane, a więc już nie własne własne formularze uwierzytelniania i bazy danych. Pewnego dnia...


71



Trudno powiedzieć, o jakiej odpowiedzi mówisz w "Nie sądzę, aby powyższa odpowiedź była" zła " - Davorak


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

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


48



SHA-512 jest również szybki, więc potrzebujesz tysięcy iteracji. - Seun Osewa
"Nie używaj szybkich algorytmów hash ... wolniejsze hashe są lepsze" - wyjaśnienie? Dokumentacja? - one.beat.consumer
Objaśnienie: Im szybciej możesz tworzyć skróty, tym szybciej może działać dowolny kontroler brutalnej siły. Wolniejsze skosy spowolnią brutalne forsowanie. Powolny algorytm skrótu sprawi, że brutalne wymuszanie będzie niepraktyczne dla dłuższych haseł (8 cyfr +) - NickG
Bardziej przypomina coś takiego jak bcrypt, który jest zaprojektowany tak, by mieszać powoli. - Fabian Nicollier


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

Dropbox Tech Blog »Blog Archive» zxcvbn: realistyczne oszacowanie siły hasła


46





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: Hasła a hasła


41





Chciałbym dodać jedną sugestię, której użyłem, w oparciu o szczegółową obronę. Nie musisz mieć tego samego systemu auth & auth dla administratorów, jak zwykli użytkownicy. Możesz mieć oddzielny formularz logowania na oddzielnym adresie URL, wykonując oddzielny kod dla żądań, które przyznają wysokie uprawnienia. Ten może dokonywać wyborów, które będą zwykłym bólem dla zwykłych użytkowników. Jednym z takich, których użyłem, jest faktyczne szyfrowanie adresu URL logowania w celu uzyskania dostępu administratora i wysłanie do administratora nowego adresu URL. Natychmiast przerywa każdy atak z użyciem siły, ponieważ nowy adres URL może być dowolnie trudny (bardzo długi losowy ciąg znaków), ale jedyną niedogodnością dla administratora jest kliknięcie łącza w wiadomości e-mail. Atakujący nie wie już, gdzie należy się POST.


20



Prosty link w e-mailu nie jest właściwie bezpieczny, ponieważ poczta e-mail nie jest bezpieczna. - David Spector
Jest tak samo bezpieczny, jak każdy inny system resetowania hasła oparty na tokenach, który nie jest jednak dwuskładnikowy. To prawie wszystkie z nich. - Iain Duncan


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

Jeśli chodzi o poing CZĘŚĆ IV: Funkcja zapomnianego hasła w pierwszej odpowiedzi chciałbym poruszyć kwestię ataków czasowych.

w Zapamiętaj swoje hasło formularze, 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).

Odnosząc się do formularza Forgotten Password, chciałbym dodać, że dobrym pomysłem jest równe czasy między trafnymi i bezmyślnymi zapytaniami z pewną funkcją opóźnienia.

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


12





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

  • "W zbiorowy,  wewnątrz- ustawienia sieci, "większość, jeśli nie wszystkie powyższe mogą nie mieć zastosowania!

Wiele korporacji wdraża witryny "wyłącznie do użytku wewnętrznego", które są faktycznie "aplikacjami korporacyjnymi", które zostały zaimplementowane za pomocą adresów URL. Te adresy URL mogą (podobno ...) rozwiązywać tylko w "wewnętrznej sieci firmy". (Która sieć magicznie obejmuje wszystkich "wojowników drogowych" połączonych z siecią VPN.) 

Kiedy użytkownik jest sumiennie związany z wyżej wymienioną siecią, jego tożsamość ("poświadczenie") jest [już ...] "jednoznacznie wiadomo", podobnie jak ich pozwolenie ("upoważnienie") robić pewne rzeczy ... takie jak ... "aby uzyskać dostęp do tej strony."

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

Z twojego punktu widzenia po prostu wiesz: to ktoś kto legalnie najeżdża na twoją stronę musi towarzyszy mu [zmienna środowiskowa magicznie zawierająca ...] "żeton". (to znaczy Brak takiego żetonu musi być natychmiastowy 404 Not Found.)

Wartość żetonu nie ma dla ciebie żadnego sensu, ale, w razie potrzeby "istnieją odpowiednie środki", za pomocą których Twoja strona internetowa może "[autorytatywnie] zapytać kogoś, kto zna (LDAP ... itd.)" o jakichkolwiek i każdy (!) pytanie, które możesz mieć. Innymi słowy, robisz nie skorzystaj z każdy "logika domowa". Zamiast tego pytasz o Władze i domyślnie ufasz jej werdyktowi.

Uh, huh ... to jest całkiem mentalna zmiana z "dzikiego i wełnianego Internetu".


10



Czy dobrze pasowałeś do interpunkcji jako dziecko? :) Przeczytałem to trzy razy i nadal jestem zagubiony w jakim punkcie próbujesz dokonać. Ale jeśli mówisz "Czasami nie potrzebujesz uwierzytelniania opartego na formularzach", masz rację. Ale biorąc pod uwagę, że dyskutujemy, kiedy tego potrzebujemy, nie rozumiem, dlaczego jest to bardzo ważne. - Hugo Delsing
Chodzi mi o to, że świat na zewnątrz korporacja jest zupełnie inna niż świat wewnątrz.  Jeśli tworzysz aplikację dostępną dla "wełnianej, szerokiej sieci" i do ogólnej konsumpcji przez publiczność, to nie masz wyboru i musisz przetasować swoje własne metody uwierzytelniania i autoryzacji. Ale wewnątrz korporacji, gdzie jedynym sposobem, aby tam dotrzeć, jest obecność lub korzystanie z VPN, jest bardzo prawdopodobne, że aplikacja nie będzie miała - nie możesz mieć - "własne" metody robienia tych rzeczy. Aplikacja musi zamiast tego użyj tych metod, aby zapewnić spójne, scentralizowane zarządzanie. - Mike Robinson
Nawet intranety wymagają minimalnego poziomu bezpieczeństwa w budynku. Sprzedaż ma poufne dane dotyczące zysków i strat, podczas gdy inżynieria ma poufną własność intelektualną. Wiele firm ogranicza dane między liniami działów lub działów. - Sablefoste