Ostateczne przewodnik do uwierzytelniania opartego na stronie formularza

głosy
4k

forma uwierzytelniania opartego na stronach internetowych

Wierzymy, że przepełnienie stosu nie powinna być tylko źródłem informacji dla bardzo konkretnych pytań technicznych, ale także do ogólnych wytycznych dotyczących sposobu rozwiązywania wariacje na wspólnych problemów. „Postać uwierzytelnianie oparte na stronach internetowych” powinno być w porządku tematem dla takiego eksperymentu.

Powinna ona obejmować takie tematy jak:

  • Jak się zalogować
  • Jak wylogować
  • Jak pozostać zalogowany
  • Zarządzanie ciasteczka (włącznie z zalecanymi ustawieniami)
  • SSL / HTTPS
  • Jak przechowywać haseł
  • Korzystanie tajne pytania
  • Zapomniany login / hasło funkcjonalność
  • Zastosowanie nonces zapobiegających cross-site request fałszerstw (CSRF)
  • OpenID
  • „Pamiętaj mnie” checkbox
  • Przeglądarka autouzupełnianie z nazw użytkowników i haseł
  • Tajne URL (publiczny adres URL chroniony przez trawienie)
  • Sprawdzanie siły hasła
  • Walidacja e-mail
  • i wiele więcej na temat uwierzytelniania opartego formy ...

Nie powinno obejmować takie rzeczy jak:

  • Role i autoryzacja
  • uwierzytelnianie podstawowe HTTP

Proszę nam pomóc poprzez:

  1. sugeruje podkategorie
  2. Złożenie dobre artykuły na ten temat
  3. Edycja oficjalną odpowiedź
Utwórz 02/08/2008 o 20:51
źródło użytkownik
W innych językach...                            


12 odpowiedzi

głosy
3k

CZĘŚĆ I: Jak zalogować

Będziemy zakładać, wiesz już, jak zbudować login + hasło formularza HTML, które stanowiska wartości do skryptu po stronie serwera w celu uwierzytelnienia. Sekcje poniżej zajmie się wzorami dla dźwięku praktycznego auth i jak uniknąć najczęstszych pułapek zabezpieczeń.

HTTPS HTTPS czy nie?

Chyba że połączenie jest już bezpieczny (czyli tunelowane poprzez HTTPS przy użyciu protokołu SSL / TLS), swoje wartości formularza logowania zostaną wysłane w postaci zwykłego tekstu, który umożliwia ktoś podsłuchiwał na linii pomiędzy przeglądarką a serwerem WWW będzie w stanie odczytać loginy jak przechodzą przez. Ten typ podsłuch jest wykonywana rutynowo przez rządy, ale w ogóle nie zajmie się „własnością” przewody inne niż do powiedzenia to: Jeśli ochrona niczego ważnego, należy użyć protokołu HTTPS.

W istocie jedynym praktycznym sposobem zapobiegania podsłuch / pakietu wąchania podczas logowania jest za pomocą protokołu HTTPS lub inny schemat szyfrowania na podstawie certyfikatu (np TLS ) lub system wyzwanie-odpowiedź sprawdzone i testowane (na przykład Diffie-Hellmana -na SRP). Każda inna metoda może być łatwo omijane przez atakującego podsłuch.

Oczywiście, jeśli są chętni, aby dostać trochę niepraktyczne, można również zatrudnić jakąś formę schematu uwierzytelniania dwuskładnikowego (np aplikacji Google Authenticator fizycznego „zimnego stylu War” słownika, lub generator klucza klucza RSA). Jeśli stosowane prawidłowo, to może pracować nawet z niezabezpieczonego połączenia, ale trudno sobie wyobrazić, że dev byłby skłonny do wdrożenia dwuskładnikowego uwierzytelniania, ale nie SSL.

(Nie) roll-your-own szyfrowanie JavaScript / mieszania

Ze względu na różną od zera koszty i postrzeganej trudność techniczną konfigurowania certyfikatu SSL na swojej stronie, niektórzy deweloperzy są kuszeni, aby rzucić swoje własne systemy hashowania lub szyfrowania w przeglądarce w celu uniknięcia przechodzenia czystym tekście loginów nad drutem niezabezpieczone.

Chociaż jest szlachetny myśl jest bezużyteczne (i może to być błąd bezpieczeństwa ), jeśli nie jest połączona z jednym z powyżej - która jest albo zabezpieczania linii z silnym szyfrowania lub stosując wypróbowaną i przetestowaną wyzwanie-odpowiedź mechanizm (jeśli nie wiesz co to jest, po prostu wiem, że jest to jeden z najtrudniejszych do udowodnienia, najbardziej trudne do zaprojektowania i najtrudniejszy do realizacji koncepcji w dziedzinie cyfrowych systemów bezpieczeństwa).

Chociaż prawdą jest, że mieszania hasło mogą być skuteczne wobec ujawnienia haseł , jest podatny na ataki odtworzeniowe, man-in-the-middle / porwania (jeśli atakujący może wstrzyknąć kilka bajtów do strony HTML niezabezpieczonej zanim dotrze do przeglądarka, mogą po prostu zakomentuj hashowania w JavaScript), lub ataki brute-force (ponieważ jesteś podając atakującego zarówno nazwę użytkownika, sól i zakodowane hasło).

CAPTCHA przeciwko ludzkości

CAPTCHA mają na celu udaremnienia jedną konkretną kategorię ataku: automatyczny słownik / brute force prób i błędów bez operatora człowieka. Nie ma wątpliwości, że jest to realne zagrożenie, jednak istnieją sposoby radzenia sobie z nim bez problemu, które nie wymagają captcha, specjalnie zaprojektowane prawidłowo Serverside systemy logowania dławienia przepływu - omówimy te później.

Wiem, że CAPTCHA implementacje nie są tworzone jednakowo; często nie są ludźmi-rozwiązywalne, większość z nich są faktycznie nieskuteczne przeciwko botom, wszystkie z nich są nieskuteczne przeciwko tanim trzeciego świata pracy (zgodnie z OWASP , obecna stawka Sweatshop jest 12 $ za 500 testów), a niektóre implementacje mogą być technicznie nielegalne w niektórych krajach (patrz OWASP Authentication Ściągawka ). Jeśli trzeba użyć CAPTCHA, użyj Google reCAPTCHA , ponieważ jest OCR-hard definicji (ponieważ używa już OCR-błędnie zaklasyfikowana skany książek) i bardzo się stara, aby być łatwy w obsłudze.

Osobiście staram się znaleźć captchas irytujące, i używać ich tylko w ostateczności, gdy użytkownik nie powiodło się, aby zalogować się kilka razy i opóźnienia są maxxed dławienia się. Stanie się to na tyle rzadko możliwe do zaakceptowania, a to wzmacnia system jako całość.

Przechowywanie haseł / loginów Weryfikacja

To może ostatecznie być powszechnie wiadomo po wszystkich głośnych hacki i wycieki danych użytkownika widzieliśmy w ostatnich latach, ale to musi być powiedziane: Nie przechowywać haseł w postaci zwykłego tekstu w bazie danych. Bazy danych użytkownika są rutynowo posiekany, przeciekał lub zbierana przez SQL injection, a jeśli są przechowywanie haseł w postaci zwykłego tekstu, surowe, że jest natychmiastowy koniec gry dla bezpieczeństwa logowania.

Więc jeśli nie można zapisać hasło, jak można sprawdzić, czy połączenie login + hasło pisał z formularza logowania jest poprawna? Odpowiedź jest mieszania za pomocą funkcji uzyskiwania klucza . Za każdym razem gdy tworzony jest nowy użytkownik lub hasło zostało zmienione, wziąć hasło i uruchomić go przez KDF, takich jak Argon2, bcrypt, scrypt lub PBKDF2, obracając tekstem jawnym hasło ( „correcthorsebatterystaple”) do długiego, losowe wyglądających sznurka , który jest o wiele bezpieczniej przechowywać w bazie danych. Aby zweryfikować logowania, należy uruchomić tę samą funkcję skrótu na wprowadzonym hasłem, tym razem przechodząc w soli i porównać wynikowy ciąg mieszania do wartości przechowywanych w bazie danych. Argon2, bcrypt i przechowywać scrypt sól z już hash. Sprawdź ten artykuł na sec.stackexchange do bardziej szczegółowych informacji.

Powodem sól jest używany dlatego mieszania w sobie nie jest wystarczające - będziemy chcieli dodać tzw „sól” w celu ochrony przed hash tęczowe tablice . Sól skutecznie zapobiega dwa hasła, które dokładnie odpowiadają przed przechowywane w tej samej wartości hash, zapobiegając cała baza danych są skanowane w jednym przebiegu, jeśli osoba atakująca realizuje hasło zgadywania ataku.

Kryptograficznych mieszania nie powinien być używany do przechowywania haseł, ponieważ wybrana przez użytkownika hasła nie są wystarczająco silne (czyli zwykle nie zawiera wystarczającej ilości entropii) oraz hasło zgadywania atak mógłby zostać zakończony w stosunkowo krótkim czasie przez atakującego z dostępem do skrótów. Dlatego stosuje się KDF - to skutecznie „rozciągnąć klawisz” co oznacza, że każde hasło odgadnąć atakujący sprawia polega iteracji algorytmu mieszania wielokrotnie, na przykład 10.000 razy, dzięki czemu hasło atakującego zgadywania 10000 razy wolniej.

Dane sesji - „Jesteś zalogowany jako Spiderman69”

Gdy serwer weryfikuje login i hasło przeciwko bazy danych użytkownika i znalazł mecz, system potrzebuje sposób na zapamiętanie, że przeglądarka została uwierzytelniona. Ten fakt tylko powinien nigdy być przechowywane po stronie serwera w danych sesji.

Jeśli nie jesteś zaznajomiony z danych sesji, oto jak to działa: jeden losowo wygenerowany ciąg jest przechowywany w pliku cookie upływającym i używane do odwoływania się do gromadzenia danych - dane sesji - która jest przechowywana na serwerze. Jeśli używasz ramy MVC, jest to niewątpliwie już obsługiwane.

Jeśli to możliwe, upewnij się, że plik cookie sesji ma bezpiecznej i HTTP tylko flagi zestawu gdy wysłane do przeglądarki. Flaga HttpOnly zapewnia pewną ochronę przed cookie są odczytywane przez atak XSS. Bezpieczny flagi gwarantuje, że plik cookie jest wysyłane tylko z powrotem za pośrednictwem protokołu HTTPS, a tym samym chroni przed atakami sieciowymi wąchania. Wartość cookie nie powinny być przewidywalne. Gdzie cookie przedstawieniu sesję nieistniejącego prezentowana jest jego wartość należy natychmiast wymienić, aby zapobiec utrwalenie sesji .

CZĘŚĆ II: Jak pozostać zalogowanym - niesławny „Remember Me” pole

Trwałe pliki cookie logowania ( „zapamiętaj mnie” funkcjonalnej) to strefa niebezpieczna; Z jednej strony, są one całkowicie bezpieczne, jak konwencjonalne jak loginy, gdy użytkownicy rozumieją, jak sobie z nimi radzić; az drugiej strony, są one ogromne zagrożenie dla bezpieczeństwa w rękach nieostrożnych użytkowników, którzy mogą z nich korzystać na komputerach publicznych i zapomnij się wylogować, a kto nie może wiedzieć, co to przeglądarka plików cookie i jak je usunąć.

Osobiście lubię uporczywe loginy do stron internetowych, które odwiedzam regularnie, ale wiem, jak radzić sobie z nimi bezpiecznie. Jeżeli jesteś pewien, że użytkownicy wiedzą, takie same, można użyć uporczywe loginy z czystym sumieniem. Jeśli nie - cóż, to możesz zapisać się do filozofii, że użytkownicy, którzy są nieostrożny z ich poświadczenia logowania przyniósł go na siebie, jeśli się włamał. To nie tak jak idziemy do domów naszych użytkowników i oderwać wszystkich tych facepalm wywołujących post-it z hasłami one ustawiły się na skraju swoich monitorach, albo.

Oczywiście, niektóre systemy nie mogą sobie pozwolić na jakiekolwiek kont hacked; dla takich systemów, nie ma sposobu, można uzasadnić konieczności uporczywe logowania.

Jeśli zdecydujesz się na wdrożenie trwałych plików cookie logowania, to jak to zrobić:

  1. Po pierwsze, trochę czasu, aby przeczytać artykuł Paragon Initiative na ten temat. Musisz dostać kilka elementów rację, a artykuł ma wielkie zadanie wyjaśnienia każda.

  2. I po prostu powtórzyć jedną z najczęstszych pułapek, nie należy przechowywać Trwały plik cookie logowania (token programowy) w bazie danych, jedynie skrót IT! Login hasło tokenu jest równoważny, więc jeśli atakujący dostał w swoje ręce swojej bazie danych, mogą korzystać z tokenów, aby zalogować się do dowolnego konta, tak jak gdyby były one w czystym tekście kombinacje login-hasło. W związku z tym, należy hashowania (według https://security.stackexchange.com/a/63438/5002 słabym hash wystarczyć do tego celu) przy zapisywaniu trwałych tokeny logowania.

CZĘŚĆ III: Korzystanie Tajne pytania

Nie wdrożyć sekretnego pytania " . Funkcja „tajnych pytań” jest zabezpieczenie anty-wzór. Czytać gazetę z linku numer 4 na liście lektura obowiązkowa. Można zapytać Sarah Palin o tym drugim, po jej Yahoo! Konto e-mail został posiekany podczas poprzedniej kampanii prezydenckiej, ponieważ odpowiedź na jej pytanie bezpieczeństwa było ... „Wasilla Szkoła”!

Nawet z pytań określonych przez użytkownika, to jest wysoce prawdopodobne, że większość użytkowników będzie wybierać między:

  • A „standard” tajne pytanie jak nazwisko panieńskie matki lub ulubionym zwierzakiem

  • Prosty kawałek błahostek, że każdy może podnieść ze swoim blogu, profilu LinkedIn lub podobny

  • Wszelkie wątpliwości, że jest łatwiej odpowiedzieć niż zgadywania hasła. Które dla każdej godnej hasła, to każde pytanie można sobie wyobrazić

Podsumowując, kwestie bezpieczeństwa są z natury niebezpieczne praktycznie we wszystkich swoich formach i odmianach, i nie powinien być stosowany w systemie uwierzytelniania z jakiegokolwiek powodu.

Prawdziwy powód, dlaczego w ogóle istnieją kwestie bezpieczeństwa w środowisku naturalnym jest to, że łatwo zaoszczędzić na kosztach kilku połączeń wsparcia ze strony użytkowników, którzy nie mogą uzyskać dostęp do swojego e-maila, aby dostać się do kodu reaktywacji. To kosztem bezpieczeństwa i reputacji Sarah Palin. Warto było? Prawdopodobnie nie.

CZĘŚĆ IV: Zapomniane hasło Funkcjonalność

I już wspomniano, dlaczego należy nigdy używać pytania zabezpieczające do obsługi zapomnianych / utraconych haseł użytkowników; to również rzeczą oczywistą, że nigdy nie należy e-mail użytkownikom ich rzeczywistych haseł. Istnieją co najmniej dwa więcej nazbyt częste pułapki, których należy unikać w tej dziedzinie:

  1. Nie zresetować zapomniane hasło do wygenerowany automatycznie silnym hasłem - takie hasła są notorycznie trudne do zapamiętania, co oznacza, że użytkownik musi albo zmienić go lub zapisać go w dół - powiedzmy, na jasny żółty post-it na skraju swojego monitora. Zamiast ustawiać nowe hasło, po prostu pozwolić użytkownikom wybrać nowy od razu - czyli to, co chcą zrobić i tak.

  2. Zawsze hash zapomniane hasło kodu / token w bazie danych. ZNOWU , kod ten jest kolejnym przykładem odpowiednik hasło, więc musi być zakodowane w przypadku atakujący dostał w swoje ręce swojej bazie danych. Kiedy stracił kod wymagane jest hasło, wyślij kod zwykłego tekstu na adres e-mail użytkownika, a następnie mieszania go zapisać skrót w bazie danych - i wyrzucić oryginału . Podobnie jak hasła lub uporczywego logowania tokena.

Ostatnia uwaga: zawsze upewnić się, że interfejs do wprowadzania kodu hasło „utraconą” jest co najmniej tak samo bezpieczne jak formularzu logowania sama lub atakujący po prostu użyć tego, aby uzyskać dostęp zamiast. Upewniając się wygenerować bardzo długo „stracił kody Hasło” (na przykład 16 wielkość liter znaków alfanumerycznych) to dobry początek, ale należy rozważyć dodanie tego samego schematu dławiący, które możesz zrobić dla samego formularza logowania.

CZĘŚĆ V: Sprawdzanie Password Strength

Po pierwsze, będziemy chcieli, aby przeczytać ten mały artykuł o sprawdzenie Rzeczywistość: Do 500 najczęstszych haseł

Ok, więc może ta lista nie jest kanoniczny lista najczęstszych haseł na dowolnym systemie gdziekolwiek kiedykolwiek , ale jest to dobry wskaźnik tego, jak źle ludzie będą wybierać swoich haseł, gdy nie ma egzekwowane polityka w miejscu. Plus, lista wygląda przerażająco blisko domu, jeśli porównać to do publicznie dostępnych analiz niedawno skradzionych haseł.

Tak: Przy braku minimalnych wymagań wytrzymałościowych hasło, 2% użytkowników użyć jednego z 20 najbardziej popularnych haseł. Czyli: jeśli atakujący dostaje tylko 20 prób, 1 w 50 kont na swojej stronie będzie do złamania.

Udaremniając wymaga obliczania entropii hasła, a następnie zastosowanie progu. The National Institute of Standards and Technology (NIST) Special Publication 800-63 posiada zestaw bardzo dobrych sugestii. To, w połączeniu z analizą układu słowniku oraz klawiatura (na przykład „QWERTYUIOP” jest złe hasło) można odrzucić 99% wszystkich haseł słabo zaznaczonych na poziomie 18 bitów entropii. Wystarczy obliczania siły hasła i pokazując wizualną miernik siły , aby użytkownik jest dobry, ale niewystarczający. O ile nie jest egzekwowane, wielu użytkowników będzie najprawdopodobniej zignorować.

I na orzeźwiającą wziąć na łatwość obsługi z wysokiej entropii hasła, Randall Munroe za Password Strength xkcd jest wysoce zalecana.

Część VI: Much More - Albo: Zapobieganie Rapid-Ogień Próby logowania

Po pierwsze, muszą zapoznać się z numerami: Prędkości Password Recovery - Jak długo będzie hasło wstać

Jeśli nie masz czasu, aby przejrzeć tabele w tym linku, oto ich lista:

  1. To trwa praktycznie żadnego czasu do zgryzienia słabego hasła, nawet jeśli pękanie go z liczydła

  2. To trwa praktycznie żadnego czasu do zgryzienia alfanumerycznego hasła 9 znaków, jeśli jest to przypadek niewrażliwe

  3. To trwa praktycznie żadnego czasu do zgryzienia skomplikowanych, symbole i-litery i-cyfr, górną i-małe hasło, jeśli jest krótsza niż 8 znaków (komputer stacjonarny może przeszukiwać całą KEYSPACE do 7 znaków w kilku dni lub nawet godziny)

  4. Byłoby jednak brać dużej ilości czasu do zgryzienia nawet hasło 6-znakowy, jeśli były ograniczone do jednej próby na sekundę!

Więc co możemy wyciągnąć z tych liczb? Cóż, wiele, ale możemy skupić się na najważniejszej części: fakt, że zapobieganie dużej liczby szybkiego ognia kolejnych prób logowania (tzn. Brute force attack) naprawdę nie jest takie trudne. Ale uniemożliwiając mu prawo nie jest tak proste jak się wydaje.

Ogólnie rzecz biorąc, masz trzy opcje, które są skuteczne wobec wszystkich ataków brute-force (i ataki słownikowe, ale skoro już jesteś zatrudniania silnej polityki haseł, nie powinno być problemu) :

  • Przedstawić CAPTCHA po N nieudanych próbach (irytujące jak diabli i często nieskuteczne - ale ja powtarzam tutaj)

  • Blokowanie kont i wymagające weryfikacji e-mail po N nieudanych próbach (jest to DoS atak czeka się stało)

  • I wreszcie, logowanie dławienia : to ustawienie opóźnienia czasowego pomiędzy próbami po N nieudanych próbach (tak, ataki DoS są nadal możliwe, ale przynajmniej są one znacznie mniej prawdopodobne i dużo bardziej skomplikowany zdjąć).

Najlepsza praktyka nr 1: krótki czas opóźnienia, które wzrasta wraz z liczbą nieudanych prób, takich jak:

  • 1 nieudanej próbie = bez opóźnienia
  • 2 błędnym = opóźnienie 2s
  • 3 błędnym = opóźnienia 4 sekundy
  • 4 błędnym = opóźnienie 8 s
  • 5 błędnym = opóźnienie 16 sek
  • itp.

DoS atakowanie tego systemu byłoby bardzo niepraktyczne, ponieważ uzyskany czas blokady jest nieco większy niż suma poprzednich czasów blokady.

Aby wyjaśnić: Opóźnienie to nie opóźnienie przed powrotem odpowiedzi do przeglądarki. To jest bardziej jak timeout lub opornym na okres, w którym próby logowania do konkretnego konta lub z określonego adresu IP nie będą przyjmowane ani oceniane w ogóle. Oznacza to, że poprawne poświadczenia nie powróci w udanym logowaniu, a nieprawidłowe poświadczenia nie będą powodować wzrost opóźnienia.

Najlepsza praktyka nr 2: Opóźnienie czasu średniej długości, które zaczną obowiązywać po N nieudanych próbach, takich jak:

  • 1-4 błędnym = bez opóźnienia
  • 5 błędnym = 15-30 minutowe opóźnienie

DoS atakowanie tego systemu byłoby dość niepraktyczne, ale na pewno wykonalne. Ponadto, może to być istotne, aby pamiętać, że taka długa zwłoka może być bardzo irytujące dla uprawnionego użytkownika. Zapominalskich użytkowników cię lubię.

Najlepsza praktyka nr 3: Łącząc te dwa podejścia - zarówno stałe, krótki czas opóźnienia, które zaczną obowiązywać po N nieudanych próbach, takich jak:

  • 1-4 błędnym = bez opóźnienia
  • Nieudane próby = 5+ 20 sekundach opóźnienia

Albo, rosnące opóźnienie ze stałym górne, jak:

  • 1 nieudaną próbę opóźnienie = 5 sek
  • 2 błędnym = 15 s opóźnienie
  • 3+ błędnym = 45 sek opóźnienia

Ten ostatni system został zabrany z OWASP najlepszych praktyk sugestii (Link 1 z listy must-read), i należy rozważyć najlepsze praktyki, nawet jeśli jest to wprawdzie na restrykcyjnej stronie.

Jako zasada Chciałbym jednak powiedzieć: im silniejsza wasza polityka hasło, tym mniej trzeba użytkownikach błąd z opóźnieniami. Jeśli wymagają silnych (CASE-czułe znaki alfanumeryczne + wymaganych liczb i symboli) 9+ haseł znaków, można dać użytkownikom 2-4 non-opóźniony prób wprowadzenia hasła przed uruchomieniem dławienia.

DoS atakuje ten ostateczny schemat logowanie dławiący byłoby bardzo niepraktyczne. I jako ostateczny szlif, zawsze pozwalają trwała (cookie) loginów (i / lub CAPTCHA zweryfikowany formularza logowania) przechodzą, więc uzasadnione użytkownicy nie będą nawet zostać opóźniony , gdy atak jest w toku . W ten sposób bardzo niepraktyczne atak DoS staje się bardzo niepraktyczne atak.

Dodatkowo, ma sens, aby zrobić bardziej agresywne dławienie na kontach administracyjnych, ponieważ są to najbardziej atrakcyjne punkty wejścia

Część VII: Rozproszone ataki brute force

Podobnie jak na marginesie, bardziej zaawansowane napastnicy będą próbować obejść logowania dławienie przez „rozprzestrzenia swoją działalność”:

  • Dystrybucją próby na botnetu, aby zapobiec bandery adresów IP

  • Zamiast podnoszenia jednego użytkownika i próbując 50.000 najczęstsze hasła (które nie mogą, ze względu na nasze dławienia), będą wybierać najczęstszych hasło i spróbuj go przed 50.000 użytkowników w zamian. W ten sposób nie tylko oni obejść maksymalnym zamachów środków takich jak CAPTCHA i logowania dławienia, ich szanse na sukces wzrasta również, ponieważ liczba 1 najczęstszym hasło jest znacznie bardziej prawdopodobne niż numer 49.995

  • Rozstaw żądań logowania dla każdego konta użytkownika, powiedzmy, 30 sekund od siebie, aby przemycić pod radarem

Oto najlepsza praktyka byłaby zalogowaniu liczbę nieudanych logowań, dla całego systemu , a przy użyciu uruchomioną średnią częstotliwością bad logowania witryny jako podstawa do górnej granicy, które następnie nałożyć na wszystkich użytkowników.

Zbyt abstrakcyjne? Pozwól mi przeformułować:

Załóżmy, że Twoja strona była średnio 120 złych logowań dziennie w ciągu ostatnich 3 miesięcy. Korzystanie że (średnio pracuje), system może ustawić globalny limit do 3 razy - tj. 360 nieudanych próbach w ciągu 24 godzin. Następnie, jeżeli łączna liczba nieudanych prób na wszystkich kontach przekracza tę liczbę w ciągu jednego dnia (lub nawet lepiej monitorować tempo przyspieszania i spust na obliczonego progu), aktywuje całego systemu logowania dławienie - czyli krótkich opóźnień dla wszystkich użytkowników (nadal, z wyjątkiem loginów ciasteczka i / lub wspomagania loginów CAPTCHA).

Ja też napisali pytanie o więcej szczegółów i bardzo dobrej dyskusji, jak uniknąć trudnych pitfals w odpierając rozproszonych atak brute force

Część VIII: dwuelementowa uwierzytelniania i uwierzytelniania dostawcy

Poświadczenia może być zagrożona, czy o wyczynach, hasła są zapisane i utracone, laptopy z kluczami kradzieży lub użytkownikom wprowadzanie loginów do stron phishingowych. Loginy mogą być dodatkowo zabezpieczone dwuskładnikowego uwierzytelniania, które wykorzystują out-of-band czynniki, takie jak kody jednorazowego użytku otrzymanych od rozmowy telefonicznej, wiadomości SMS, aplikacji lub klucza. Kilku dostawców oferuje usługi uwierzytelniania dwuskładnikowego.

Autoryzacja może być całkowicie przekazane do usługi single-sign-on, gdy inny dostawca obsługuje zbierania referencji. To popycha problem do zaufanej strony trzeciej. Google i Twitter zapewniają zarówno oparte na standardach usługi SSO, podczas gdy Facebook oferuje podobne rozwiązanie zastrzeżonych.

Koniecznie przeczytaj linki o uwierzytelniania internetowego

  1. OWASP Guide To Authentication / OWASP Authentication Ściągawka
  2. Dos i niemile widziane uwierzytelniania klienta w sieci (referatu bardzo czytelny MIT)
  3. Wikipedia: HTTP Cookie
  4. Osobiste pytania Wiedza dla uwierzytelniania awaryjnej: kwestie bezpieczeństwa w dobie Facebook (bardzo czytelny referatu Berkeley)
Odpowiedział 25/01/2009 o 12:27
źródło użytkownik

głosy
382

ostateczne Artykuł

Przesyłanie danych uwierzytelniających

Jedynym praktycznym sposobem, aby wysłać poświadczenia 100% bezpiecznie jest za pomocą protokołu SSL . Korzystanie JavaScript hash hasła nie jest bezpieczne. Typowe pułapki dla hasła po stronie klienta, mieszaja:

  • Jeśli połączenie między klientem a serwerem jest szyfrowane wszystko co robisz jest podatny na ataki typu man-in-the-middle . Osoba atakująca może zastąpić przychodzące javascript, aby przerwać hashowania lub przesyłania wszystkich poświadczeń do serwera, mogli wysłuchać odpowiedzi klienta i podszywania się pod użytkowników doskonale itd itp SSL z zaufanych urzędów certyfikacji jest przeznaczony do zapobiegania atakom MiTM.
  • Zaszyfrowany hasło otrzymane przez serwer jest mniej bezpieczny , jeśli nie robić dodatkowych, zbędnych prac na serwerze.

Jest jeszcze jedna bezpieczna metoda zwana SRP , ale to opatentowany (chociaż jest ona swobodnie licencjonowany ) i istnieje kilka dobrych implementacje dostępne.

przechowywanie haseł

Nigdy nie przechowywać haseł w postaci zwykłego tekstu w bazie danych. Nawet jeśli nie dbają o bezpieczeństwo swojej własnej strony. Zakładamy, że niektórzy użytkownicy będą używać ponownie hasło swojego internetowego konta bankowego. Więc przechowywać hasła zaszyfrowaną, i wyrzucić oryginału. I upewnij się, że hasło nie pojawi się w logach dostępowych lub dzienników aplikacji. OWASP zaleca stosowanie Argon2 jako pierwszego wyboru dla nowych zastosowań. Jeśli nie jest to możliwe, PBKDF2 lub scrypt powinien być stosowany zamiast. I wreszcie, jeśli żadna z powyższych są dostępne, użyj bcrypt.

Hashe same w sobie są również niebezpieczne. Na przykład, identycznych haseł znaczy identycznych skrótów - to sprawia, że hash tablic przeglądowych skuteczny sposób pękania wiele haseł na raz. Zamiast przechowywać solona hash. Sól jest ciągiem dołączone do hasło przed wycieniowanie - używać innego (losowa), soli na użytkownika. Sól jest wartością publicznego, dzięki czemu można przechowywać je mieszania w bazie danych. Zobacz tutaj więcej na ten temat.

Oznacza to, że nie można wysłać użytkownikowi ich zapomnianych haseł (bo masz tylko hash). Nie zresetować hasło użytkownika, chyba że uwierzytelniony użytkownik (użytkownicy muszą udowodnić, że są w stanie czytać e-maile wysyłane do zapamiętanej (i potwierdzonych) adres e-mail).

Pytania bezpieczeństwa

Kwestie bezpieczeństwa są niepewne - unikać ich stosowania. Czemu? Wszystko to kwestia bezpieczeństwa robi, hasło robi lepiej. Czytaj Część III: Użycie Tajne pytania w @Jens Roland odpowiedzieć tutaj w tej wiki.

session cookies

Gdy użytkownik loguje się, serwer wysyła użytkownikowi cookie sesji. Serwer może pobrać nazwę użytkownika lub ID z pliku cookie, ale nikt inny nie może wygenerować taki plik cookie (TODO wyjaśnić mechanizmy).

Cookies mogą być porwany : są tylko tak bezpieczne jak reszta maszynie klienta i inne komunikaty. Mogą być one odczytywane z dysku, powąchał w ruchu sieciowym, podnoszone przez atak cross-site scripting, phished z zatrutego DNS więc klient wysyła swoje ciasteczka do niewłaściwych serwerów. Nie wysyłaj trwałych plików cookie. Cookies powinny wygasnąć z końcem sesji klienta (zamknij przeglądarkę lub pozostawiając swoją domenę).

Jeśli chcesz AutoLogin użytkowników, można ustawić trwały plik cookie, ale powinno to być odrębny od cookie pełnej sesji. Można ustawić dodatkową flagę, że użytkownik ma automatycznie zalogowany i wymaga, aby zalogować się na rzeczywistym operacji wrażliwych. Jest to popularne z witryn handlowych, które chcą zapewnić Państwu bezproblemową, spersonalizowanego doświadczenia handlowego, ale nadal chronić swoje dane finansowe. Na przykład, gdy wrócisz do odwiedzenia Amazon, oni pokazać stronę, która wygląda jak jesteś zalogowany, ale kiedy idziesz do złożenia zamówienia (lub zmienić adres wysyłki, karta kredytowa itp), proszą o potwierdzenie Twoje hasło.

Finansowe witryn internetowych, takich jak banki i kart kredytowych, z drugiej strony, tylko dane wrażliwe i nie powinny umożliwić automatyczne logowanie lub tryb niskiego bezpieczeństwa.

Lista środków zewnętrznych

Odpowiedział 02/08/2008 o 21:40
źródło użytkownik

głosy
146

Po pierwsze, silna zastrzeżenie, że ta odpowiedź nie jest najlepiej pasuje do dokładnie tej kwestii. To nie powinno być zdecydowanie górna odpowiedź!

Będę śmiało wymienić Mozilli proponowaną BrowserID (albo dokładniej Verified Email Protocol ) w duchu znalezienie upgrade'u do lepszych podejść do uwierzytelniania w przyszłości.

Ja to podsumować w ten sposób:

  1. Mozilla jest niedochodową z wartościami , które align dobrze ze znalezieniem dobrych rozwiązań tego problemu.
  2. Rzeczywistość jest taka, że ​​dzisiaj większość stron korzysta z uwierzytelniania opartego na formularzu
  3. Uwierzytelniania opartego na formularzu ma dużą wadę, która jest zwiększone ryzyko phishing . Użytkownicy proszeni są o podanie poufnych informacji do obszaru kontrolowanego przez zdalnej jednostki, zamiast na obszarze kontrolowanym przez ich agenta użytkownika (przeglądarki).
  4. Od przeglądarek zaufany niejawnie (cała idea aplikacja kliencka jest do działania w imieniu użytkownika), mogą przyczynić się do poprawy tej sytuacji.
  5. Podstawową siłą trzyma tutaj z powrotem postęp jest impas rozmieszczania . Rozwiązania muszą być rozłożone na etapy, które zapewniają pewne przyrostowe korzyści na własną rękę.
  6. Najprostszy sposób zdecentralizowany do wyrażania tożsamości, który jest wbudowany w infrastrukturę Internetu jest nazwą domeny.
  7. Jako drugi poziom wyrażania tożsamości, każda domena zarządza własny zestaw kont.
  8. Postać „rachunek @domena” jest zwięzły i obsługiwane przez szereg protokołów, i systemach URI. Taki identyfikator jest, oczywiście, najbardziej powszechnie uznawane jako adres e-mail.
  9. dostawcy usług pocztowych są już de facto dostawcy podstawowej tożsamości w Internecie. Płynie prąd resetowania hasła zazwyczaj pozwalają przejąć kontrolę nad kontem, jeśli można udowodnić, że można kontrolować skojarzony adres e-mail konta.
  10. Verified Email Protokół został zaproponowany w celu zapewnienia bezpiecznej metody, oparte na kryptografii klucza publicznego, usprawnienie procesu okazuje się domeną B, że masz konto w domenie A.
  11. Dla przeglądarek, które nie obsługują weryfikować Email Protocol (obecnie wszystkie z nich), Mozilla dostarcza podkładkę, która implementuje protokół po stronie klienta w kodzie JavaScript.
  12. W przypadku usług pocztowych, które nie obsługują Verified Email Protocol, protokół umożliwia stronom trzecim działają jako zaufanego pośrednika, twierdząc, że zweryfikujesz własność użytkownika z konta. Nie jest pożądane, aby mieć dużą liczbę takich stron trzecich; Możliwość ta jest przeznaczona wyłącznie w celu umożliwienia upgrade'u i jest lubiany, że usługi pocztowe zapewnić sobie tych twierdzeń.
  13. Mozilla oferuje własne usługi do działania jako taką zaufaną stronę trzecią. Usługodawców (czyli Powołując się Strony) wykonawcze weryfikować Email Protokół może wybrać zaufać twierdzeń Mozilli czy nie. usługa Mozilli sprawdza własności konta użytkowników przy użyciu konwencjonalnych środków wysłanie e-maila z linkiem potwierdzającym.
  14. Usługodawcy mogą, oczywiście, oferują tego protokołu jako dodatkowa opcja w stosunku do każdej innej metody (y) może uwierzytelniania, które chcą oferować.
  15. Dużą zaletą interfejsu użytkownika poszukiwane są tutaj jest „selektor tożsamość”. Gdy użytkownik odwiedza witrynę i wybiera do uwierzytelniania, ich przeglądarka pokazuje im wybór adresów e-mail ( „osobisty”, „praca”, „aktywizm polityczny”, etc.) mogą używać do identyfikowania się do serwisu.
  16. Inną wielką zaletą interfejsu użytkownika są poszukiwane jako część tego wysiłku jest pomaganie przeglądarka wiedzieć więcej o sesji użytkownika - kim jesteś zalogowany jak obecnie, przede wszystkim - tak może on wykazywać, że w przeglądarce Chrome.
  17. Ze względu na rozproszony charakter tego systemu, unika lock-in do głównych zabytków, takich jak Facebook, Twitter, Google, itp Każda osoba może posiadać własną domenę i dlatego działają jako dostawcy własnej tożsamości.

To nie jest ściśle „forma uwierzytelniania opartego na stronach internetowych”. Ale to jest próbą przejścia z obecnego normą uwierzytelniania opartego na formularzu na coś bardziej bezpiecznego: uwierzytelnianie przeglądarce obsługiwane.

Odpowiedział 08/08/2011 o 16:32
źródło użytkownik

głosy
120

Po prostu myślałem, że będę dzielić się z tego rozwiązania, że ​​znalazłem się działać dobrze.

Ja nazywam to atrapa Pole (choć jeszcze nie wymyślił tego tak mnie nie kredytowej).

W skrócie: po prostu trzeba wstawić to do swojego <form>i sprawdzić, że jest pusty w czasie sprawdzania:

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

Sztuką jest, aby oszukać bota do myślenia, że musi wstawić dane do wymaganego pola, dlatego nazwałem wejściowych „e-mail”. Jeśli masz już pole o nazwie e-mail, który używasz należy spróbować nazywania atrapę pole coś innego jak „Spółka”, „telefon” lub „EMAILADDRESS”. Wystarczy wybrać coś wiesz, że nie jest konieczne, a co brzmi jak coś ludzi normalnie znaleźć logiczne wypełnić w formularzu internetowym. Teraz ukryć inputpole za pomocą CSS lub JavaScript / jQuery - cokolwiek ci pasuje najlepiej - po prostu nie ustawić wejście typedo hiddenlub inny bot nie spadnie na niego.

Podczas walidacji formularza (klient lub po stronie serwera) sprawdza, czy pozorowane pole zostało wypełnione, aby określić, czy było wysłać przez człowieka lub bot.

Przykład:

W przypadku człowieka: Użytkownik nie będzie widać pole obojętne (w moim przypadku o nazwie „e-mail”) i nie będzie próbował go wypełnić. Tak więc wartość pola manekina powinna nadal być pusty, gdy formularz został wysłany.

W przypadku bota: bot zobaczy pole, którego typ jest texti nazwisko email(lub cokolwiek to nazwał) i logicznie próbować wypełnić go z odpowiednimi danymi. To nie obchodzi jeśli stylizowany formularz wejściowy z jakiegoś nadzwyczajnego CSS, Web-developerzy robią to cały czas. Niezależnie od wartości w polu manekina jest taka, że nie obchodzi tak długo, jak to jest większy niż 0znaków.

Użyłem tej metody w księdze gości w połączeniu z CAPTCHA , a ja nie widziałem pojedynczy słupek od spamu. I użył rozwiązania CAPTCHA tylko przed, ale w końcu to spowodowało około pięć stanowisk spamu co godzinę. Dodanie pola manekin w formie przestał (przynajmniej dotychczas) cały spam pojawianiu.

Wierzę, że to może być również stosowany w porządku z formularzem logowania / uwierzytelniania.

Ostrzeżenie : Oczywiście ta metoda nie jest w 100% dowód głupcem. Boty mogą być zaprogramowana do ignorowania pól wejściowych ze stylem display:noneprzyłożonego do niego. Trzeba też pomyśleć o ludziach, którzy korzystają z jakiejś formy autouzupełnianie (jak większość przeglądarek ma wbudowaną!) Do Autouzupełniany wszystkich pól formularza dla nich. Mogą równie dobrze odebrać pole obojętne.

Można również zmieniać się to trochę przez opuszcza boiska atrapę widoczny ale poza granice ekranu, ale to jest całkowicie do Ciebie.

Bądź kreatywny!

Odpowiedział 22/05/2012 o 13:11
źródło użytkownik

głosy
71

Nie sądzę powyższego odpowiedź brzmi „nie tak”, ale istnieją duże obszary uwierzytelniania, które nie zostały poruszone (lub raczej nacisk kładzie się na „jak wdrożyć sesje cookies”, a nie „jakie opcje są dostępne i jakie są handlu off”.

My je Montaż / odpowiedzi są

  • Problem tkwi w konfiguracji konta niż w kontroli haseł.
  • Zastosowanie czynnika dwa authenitication jest o wiele bardziej bezpieczne niż bardziej sprytnych pomocą szyfrowania haseł
  • Nie staraj się wdrożyć własny formularz logowania lub przechowywania bazy danych haseł, chyba że zostaną zapisane dane jest bezwartościowe przy tworzeniu konta i samogenerujące (czyli w stylu Web 2.0, takich jak Facebook, Flickr , itp)

    1. Uwierzytelnianie Digest jest standardy Podejście oparte obsługiwane we wszystkich głównych przeglądarek i serwerów, które nie wyśle ​​hasło nawet przez bezpieczny kanał.

Dzięki temu unika się konieczności posiadania „sesje” lub ciasteczka jako przeglądarka sama ponownie zaszyfrować komunikację za każdym razem. Jest to najbardziej „lekkie” podejście do rozwoju.

Jednak nie jest to zalecane, z wyjątkiem publicznych, usług o niskiej wartości. Jest to problem, z niektórych innych odpowiedzi powyżej - nie spróbować ponownej implementacji mechanizmów authetication server-side - problem ten został rozwiązany i jest obsługiwany przez większość głównych przeglądarek. Nie używać cookies. Czy coś w swoim własnym ręcznie zwijane bazy danych nie przechowywać. Wystarczy zapytać, na żądanie, jeśli wniosek autheticated. Wszystko inne powinno być poparte konfiguracji i trzeciej zaufanego oprogramowania.

Więc ...

Po pierwsze, są mylące początkowego tworzenia konta (z hasłem) z ponownego sprawdzenia hasła późniejszym. Jeśli jestem Flickr i tworzenia witryny po raz pierwszy, nowy użytkownik ma dostęp do wartości zerowej (puste przestrzeni internetowej). I naprawdę nie obchodzi, jeśli osoba tworzenia konta leży o ich nazwy. Jeśli tworzę konto szpitala intranet / extranet, wartość leży we wszystkich dokumentacji medycznej, a więc nie dbają o tożsamości (*) twórcy konta.

To jest bardzo, bardzo twarde części. Tylko przyzwoite rozwiązanie to internetowy zaufania. Na przykład, możesz przyłączyć się do szpitala jako lekarz. Utworzyć stronę internetową gospodarzem gdzieś ze swoim zdjęciem, numer paszportu i klucza publicznego, a hash je wszystkie za pomocą klucza prywatnego. Następnie odwiedzić szpital i administrator systemu patrzy na paszporcie, widzi jeśli zdjęcie pasuje ci, a następnie skróty stronie WWW / zdjęć mieszania ze szpitalem klucza prywatnego. Od teraz możemy bezpiecznie wymieniać klucze i tokenów. Jak może ktoś, kto ufa szpitala (nie jest tajemnicą, sos BTW). Administrator systemu może również daje RSA klucza uwierzytelniania lub innego dwuskładnikowego.

Ale to dużo kłopotów, a nie bardzo web 2.0. Jednak jest to jedyny bezpieczny sposób na tworzenie nowych kont, które mają dostęp do cennych informacji, które nie jest samo-stworzone.

  1. Kerberos i SPNEGO - pojedynczy znak na mechanizmach z zaufaną stronę trzecią - w zasadzie użytkownik sprawdza przed zaufaną stronę trzecią. (NB nie jest to w żaden sposób nie można ufać OAuth )

  2. SRP - rodzaj uwierzytelniania hasłem sprytnego bez zaufaną stronę trzecią. Ale tutaj mamy do dostania się do sfery „bezpieczniej jest korzystać z dwóch uwierzytelnienie, nawet jeśli to droższa”

  3. SSL po stronie klienta - dać klientów certyfikat klucza publicznego (wsparcie we wszystkich głównych przeglądarek - ale rodzi pytania na Client Security maszynowego).

W końcu jest to kompromis - co jest koszt naruszenia bezpieczeństwa vs kosztów wdrożenia bardziej bezpiecznych metod. Jeden dzień, możemy zobaczyć właściwą PKI powszechnie akceptowane i tak nie więcej własnej formy uwierzytelniania walcowane i baz danych. Pewnego dnia...

Odpowiedział 08/08/2011 o 17:29
źródło użytkownik

głosy
48

Podczas mieszania, nie należy używać szybkich algorytmów mieszania takich jak MD5 (istnieje wiele implementacje sprzętowe). Użyj coś jak SHA-512. Haseł, wolniejsze mieszań są lepsze.

Im szybciej można tworzyć skrótów, tym szybciej każdy brute force kontroler może pracować. Wolniejsze mieszań będzie zatem spowolnić brute zmusza. Powolny algorytm hash uczyni brute zmusza niepraktyczne dla dłuższych haseł (8 cyfr +)

Odpowiedział 09/08/2011 o 00:07
źródło użytkownik

głosy
46

Dobry artykuł o realistyczne oszacowanie wytrzymałości hasło to:

Dropbox Tech Blog »Blog Archive» zxcvbn: realistyczne oszacowanie wytrzymałości hasło

Odpowiedział 08/11/2012 o 12:15
źródło użytkownik

głosy
41

Mój ulubiony przepis w odniesieniu do systemów uwierzytelniania: stosować do odgadnięcia haseł, a nie haseł. Łatwe do zapamiętania, trudne do złamania. Więcej informacji: Coding Horror: Hasła vs. fraz

Odpowiedział 24/11/2012 o 22:15
źródło użytkownik

głosy
20

Chciałbym dodać jeszcze jedną sugestię Mam używany, na podstawie głębokiej obrony. Nie trzeba mieć taki sam auth & auth system dla administratorów jak zwykłych użytkowników. Możesz mieć osobny formularz logowania na osobnej url wykonującego oddzielny kod dla żądań, które przyznają wysokie przywileje. Ten może dokonywać wyborów, które byłyby w sumie ból do zwykłych użytkowników. Jednym z takich, które użyłem jest faktycznie wyścig URL logowania dla dostępu administratora i e-mail Admin nowy adres URL. Zatrzymuje dowolny atak brute force razu jako nowy adres URL może być dowolnie trudne (bardzo długo losowy ciąg znaków), ale administrator autora Jedyną niedogodnością jest następujący link w ich e-mail. Atakujący nie wie, gdzie nawet pocztą na.

Odpowiedział 18/07/2015 o 01:18
źródło użytkownik

głosy
12

I dont't wiem, czy to było najlepiej odpowiedzieć na to jako odpowiedź lub komentarz. Zdecydowałem się na pierwszej opcji.

Odnośnie Poing Część IV: Zapomniane hasło Funkcjonalność w pierwszej odpowiedzi, chciałbym zrobić punkt o czas ataków.

W pamiętasz hasła formach, atakujący może potencjalnie sprawdzić pełną listę e-maili i wykrywania, które są zarejestrowane w systemie (patrz link poniżej).

Odnośnie Zapomniałeś hasło formularz, chciałbym dodać, że jest to dobry pomysł, aby dorównać razy między udanych i unsucessful zapytań z pewną funkcją opóźnienia.

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

Odpowiedział 16/08/2015 o 17:31
źródło użytkownik

głosy
10

Chciałbym dodać jeszcze jedną bardzo ważną-komentarz:

  • „W korporacji, wewnątrz- ustawienia netto” większość, jeśli nie wszystkie z powyższych może nie stosować!

Wiele korporacji wdrożyć „użytku wewnętrznego” stron internetowych, które są skutecznie, „Aplikacje korporacyjne”, które zdarzają się, że zostały wdrożone poprzez adresy URL. Adresy te można (podobno ...) być rozwiązane tylko w ramach „sieci wewnętrznej firmy.” (Która sieć VPN magicznie obejmuje wszystkie podłączone „wojownicy drogowe”).

Gdy użytkownik jest połączony sumiennie wspomnianej sieci, ich tożsamość ( „authentication”) jest [już ...] „jednoznacznie wiadomo,” jak jest ich zgody ( „zezwolenie”) do robienia pewnych rzeczy ... takie jak. .. „aby uzyskać dostęp do tej strony.”

Ten „autoryzacja + zezwolenie” usługi mogą być świadczone przez kilku różnych technologii, takich jak LDAP (Microsoft OpenDirectory) lub Kerberos.

Z punktu-of-view, po prostu o tym wiedzą: że ktoś , kto legalnie nakręca się na swojej stronie musi . „Żeton” towarzyszyć [środowisko zawierające zmienną magicznie ...] ( Tj Brak takiego tokena musi być natychmiastowe podstawy 404 Not Found).

Wartość tokena jest bez sensu do Ciebie, ale, jeżeli zajdzie taka potrzeba, „istnieją odpowiednie środki”, przez co Twoja strona internetowa może „[autorytatywnie] poprosić kogoś, kto wie (LDAP ... itd)” o każdy i każda ( !) pytanie, które może być. Innymi słowy, czy nie skorzystania z jakiegokolwiek „logiki rodzimych”. Zamiast zapytać Urzędu i mieć zaufanie do jego werdykt.

Aha ... to dość psychicznego przełącznik z „dzikim i-wełnisty Internecie.”

Odpowiedział 29/04/2015 o 01:06
źródło użytkownik

głosy
5

Użyj OpenID Connect lub zarządzanych przez użytkowników dostępu .

Ponieważ nic nie jest bardziej wydajny niż nie robić w ogóle.

Odpowiedział 10/08/2016 o 13:27
źródło użytkownik

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more