Co to jest Slack? [[Rozwiązany](/forum/komunikatory-poczta-10/solved)/Zamknięty ]




 I jak działa?
taki komunikator, który możesz połączyć np z dokumentami Google
Hej Mac Dalen,
 
Poczytaj: https://support.google.com/mail/answer/21289
Tam masz wszystko opisane.
 
Pozdrawiam,
Jacek nie ma sprawy :wink: 
zaznacz post, który rozwiązał problem. 
[obraz] 
w razie kolejnych kłopotów, służę pomocą :+1: 
pozdrawiam serdecznie 
juliusz 
[stopa] założmy że rozmawiasz z jakąś tam ola.i na górze, gdzie ejst jej imie i nazwisko jest taka jakby kamerka i kóleczko z zygzakowatym brzegiem.klikasz na to kółeczko i tam mas zopcje żeby pzrejść do trybu offline dla tej osoby;0 potrzebujesz serwera vpn (może być router z funkcją vpn, lub komputer z zainstalowanym odpowiednim oprogramowaniem).
dowolna dystrybucja linuksa z zainstalowanym serwerem samba ( <https://www.samba.org/> ) 
instrukcję konfiguracji masz na stronie oraz w samym pliku konfiguracyjnym na dysku w postaci … ok, teraz rozumiem
w razie potrzeby jestem otwarty na pytania,
pozdrawiam:) Cześć,  

większości zadziałało wszystko ok. Dziękuje za obecność i słuszne uwagi.


Przepraszam tych, którzy mieli trudności.  

Jeżeli macie maile z Władcy Sieci [Rafał Gołębiowski](https://wladcysieci.pl/profile/rafal-golebiowski/).pl w spamie lub w innych folderach to dodajcie jako „nie spam”  aby skrzynka poprawnie czytała przyszłe maile. U mnie np. Onet i firmowa daje do odbiorczej ale rozumiem, że różnie bywa.


Jeśli nie załapaliście się na całość to jest <https://www.facebook.com/wladcysiecipl/>  

Dołożymy nagranie na serwis. Transmisja live nie koniecznie będzie przy wszystkich webinarach i stąd konieczność rejestracji – większość ekspertów prosi o publikacje materiałów tylko za jakimś dostępem.  Tym razem dzięki uprzejmości mamy wszystko nagrane.


Co do działania serwisu i przerw – to dostawca serwera – i wymienię z nazwy OVH – w ostatnich dniach wystawił nas na potężną próbę cierpliwości. Ponoć backupują klastry serwerów. Stąd rozważamy przenosiny jeśli na dniach się nie poprawi sytuacja. wersja standard nie jest już dostępna do pobrania, ale można pobrać wersje basic, która i tak jest używana przez większość ludzi z tego powodu, że standard obsługiwał tylko sms-y. basic pobierzesz [tutaj](https://github.com/verlikylos/vmcshop-basic) i jak masz jakieś problemy to sprawdź [faq](https://voxele.pl/t/vmcshop-basic-v1-0-1-faq/452) 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](https://en.wikipedia.org/wiki/Transport_Layer_Security) ) lub system wyzwanie-odpowiedź sprawdzone i testowane (na przykład [Diffie-Hellmana](http://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange) -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](https://stackoverflow.com/questions/1380168/does-it-make-security-sense-to-hash-password-on-client-end) ), 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](http://en.wikipedia.org/wiki/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](http://en.wikipedia.org/wiki/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](https://www.owasp.org/index.php/Authentication_Cheat_Sheet) ). Jeśli trzeba użyć CAPTCHA, użyj Google [reCAPTCHA](http://en.wikipedia.org/wiki/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](https://en.wikipedia.org/wiki/Key_derivation_function) . 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ł](https://security.stackexchange.com/a/31846/8340) 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](https://en.wikipedia.org/wiki/Rainbow_table) . 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”](https://en.wikipedia.org/wiki/Key_stretching) 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](https://www.owasp.org/index.php/Session_fixation) .


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](https://paragonie.com/blog/2015/04/secure-authentication-php-with-long-term-persistence) 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ł](http://www.whatsmypass.com/?p=415)


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](http://en.wikipedia.org/wiki/Password_strength#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](http://cubicspot.blogspot.com/2012/01/how-to-calculate-password-strength-part.html) na poziomie 18 bitów entropii. Wystarczy obliczania siły hasła i [pokazując wizualną miernik siły](https://blogs.dropbox.com/tech/2012/04/zxcvbn-realistic-password-strength-estimation/) , 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](https://xkcd.com/936/) 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ć](http://www.lockdown.co.uk/?pg=combi&s=articles)


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](http://en.wikipedia.org/wiki/Denial-of-service_attack) 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](https://stackoverflow.com/questions/479233/what-is-the-best-distributed-brute-force-countermeasure) 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](https://www.owasp.org/index.php/Authentication_Cheat_Sheet) / [OWASP Authentication Ściągawka](https://www.owasp.org/index.php/Authentication_Cheat_Sheet)
2. [Dos i niemile widziane uwierzytelniania klienta w sieci (referatu bardzo czytelny MIT)](https://pdos.csail.mit.edu/papers/webauth:sec10.pdf)
3. [Wikipedia: HTTP Cookie](http://en.wikipedia.org/wiki/HTTP_cookie#Drawbacks_of_cookies)
4. [Osobiste pytania Wiedza dla uwierzytelniania awaryjnej: kwestie bezpieczeństwa w dobie Facebook (bardzo czytelny referatu Berkeley)](http://cups.cs.cmu.edu/soups/2008/proceedings/p13Rabkin.pdf) znalazłem, zrobiłem i działa :slight\_smile: dziękuję ci bardzo. Hej!  
  
Wg. mojej najlepszej wiedzy - nie da sie tego wylaczyc.  
A z ciekawosci - czemu chcesz to wylaczyc? Dla mnie jest to pomocne do sprawdzenia gdzie dany link prowadzi zanim na niego klikne...czasami zabezpieczy mnie to przed podejrzanymi stronami...  
Pozdr.//M