Ostateczny Artykuł

Wysyłanie poświadczeń

Jedynym praktycznym sposobem wysyłania poświadczeń w 100% bezpiecznie jest użycie SSL. Używanie JavaScript do hashowania hasła nie jest bezpieczne. Najczęstsze pułapki hashowania haseł po stronie klienta:

• Jeśli połączenie między Klientem a serwerem jest niezaszyfrowane, wszystko, co robisz, jest podatne na ataki typu man-in-the-middle . Atakujący może zastąpić przychodzący javascript, aby przerwać haszowanie lub wysłać wszystkie poświadczenia do ich serwera, mogli słuchać odpowiedzi klientów i podszywać się pod użytkowników doskonale, itp. itd. Protokół SSL z zaufanymi urzędami certyfikującymi ma na celu zapobieganie atakom MitM.
• hashowane hasło odebrane przez serwer jest mniej bezpieczne Jeśli nie wykonasz dodatkowej, nadmiarowej pracy na serwerze.

Istnieje inna bezpieczna metoda o nazwie SRP , ale jest opatentowana (chociaż jest to na licencji) i jest niewiele dobrych dostępne wdrożenia.

Przechowywanie haseł

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

Hasze same w sobie również są niepewne. Na przykład, identyczne hasła oznaczają identyczne hasze-to sprawia, że tabele wyszukiwania hash są skutecznym sposobem łamania wielu haseł jednocześnie. Zamiast tego przechowuj solony hash. Salt to ciąg znaków dołączany do hasła przed hashowaniem - użyj innej (losowej) soli na użytkownika. Sól jest wartość publiczna, dzięki czemu można przechowywać je z hash w bazie danych. Zobacz tutaj aby dowiedzieć się więcej na ten temat.

Oznacza to, że nie możesz wysłać użytkownikowi zapomnianych haseł (ponieważ masz tylko hash). Nie Resetuj hasła użytkownika, dopóki nie uwierzytelnisz użytkownika (Użytkownicy muszą udowodnić, że są w stanie odczytać wiadomości e-mail wysłane na przechowywany (i zweryfikowany) adres e-mail.)

Pytania bezpieczeństwa

Pytania bezpieczeństwa są niebezpieczne-unikaj ich używania. Dlaczego? Anything a pytanie zabezpieczające robi, hasło robi lepiej. Czytaj Część III: Korzystanie z tajnych pytań w @ Jens Roland odpowiedz tutaj w tej wiki.

Sesyjne pliki cookie

Po zalogowaniu się, serwer wysyła użytkownikowi plik cookie sesji. Serwer może pobrać nazwę użytkownika lub id z pliku cookie, ale nikt inny nie może wygenerować takiego pliku cookie(aby wyjaśnić mechanizmy).

Pliki cookie mogą zostać przechwycone: są tak bezpieczne, jak reszta klientów Maszyny i inne środki komunikacji. Mogą być odczytywane z dysku, wąchane w ruchu sieciowym, podnoszone przez atak skryptów między stronami, phished z zatrutego DNS więc klient wysyła swoje pliki cookie do niewłaściwych serwerów. Nie wysyłaj trwałych plików cookie. Pliki cookie powinny wygasnąć po zakończeniu sesji klienta(zamknięcie przeglądarki lub opuszczenie domeny).

Jeśli chcesz autologować użytkowników, możesz ustawić trwały plik cookie, ale powinien on różnić się od pliku cookie pełnej sesji. Możesz ustawić dodatkowa flaga, że użytkownik ma automatycznie zalogowany i musi zalogować się na żywo dla wrażliwych operacji. Jest to popularne wśród witryn zakupowych, które chcą zapewnić Ci bezproblemowe, spersonalizowane zakupy, ale nadal chronić Twoje dane finansowe. Na przykład, po powrocie do odwiedzenia Amazon, pokazują one stronę, która wygląda jakbyś był zalogowany, ale kiedy idziesz do złożenia zamówienia (lub zmienić adres wysyłki, kartę kredytową ITP.), proszą o potwierdzenie swojego hasło.

Lista zasobów zewnętrznych

• Pliki cookies wykorzystywane są w celu świadczenia usług na najwyższym poziomie.]} 21 strona artykuł akademicki z wieloma świetnymi wskazówkami.
• Ask YC: Best Practices for User Authentication
  Forum dyskusyjne na ten temat
• prawdopodobnie jesteś Niepoprawne Przechowywanie Haseł
  Artykuł wprowadzający o przechowywaniu haseł
• dyskusja: kodowanie horroru: prawdopodobnie błędnie przechowujesz hasła
  Forum dyskusyjne na temat artykułu o kodowaniu horroru.
Nigdy nie przechowuj haseł w bazie danych!
Kolejne ostrzeżenie o przechowywaniu haseł w bazie danych.
• łamanie haseł
  Artykuł w Wikipedii o słabościach kilku schematów hashowania haseł.
• Dość Z Rainbow Tables: Co Musisz Wiedzieć O Bezpiecznych Schematach Haseł
  Dyskusja o tęczowych tablicach i o tym, jak się przed nimi bronić i przed innymi wątkami. Zawiera obszerną dyskusję.

Po pierwsze, mocne zastrzeżenie, że ta odpowiedź nie jest najlepsza dla tego pytania. To zdecydowanie nie powinna być najlepsza odpowiedź!

Wspomnę o proponowanym przez MozillęBrowserID (a może dokładniej, Verified Email Protocol ) w duchu znalezienia ścieżki uaktualnienia do lepszego podejścia do uwierzytelniania w przyszłości.

Podsumuję to w ten sposób:

1. Mozilla jest organizacją non-profit z wartościami , które dobrze się zgadzają ze znalezieniem dobrych rozwiązań tego problemu.
W dzisiejszych czasach większość stron internetowych korzysta z uwierzytelniania opartego na formularzach.]}
2. uwierzytelnianie oparte na formularzach ma dużą wadę, którą jest zwiększone ryzyko phishingu. Użytkownicy są proszeni o wprowadzenie poufnych informacji do obszaru kontrolowanego przez zdalny podmiot, a nie obszaru kontrolowanego przez ich agenta użytkownika (przeglądarkę).
3. ponieważ przeglądarki są niejawnie zaufane (cała idea agenta użytkownika polega na działaniu w imieniu Użytkownika), mogą pomóc poprawić tę sytuację.
4. główną siłą powstrzymującą postęp tutaj jest impas rozmieszczenia . Rozwiązania muszą być rozłożone na etapy, które same w sobie przynoszą pewne przyrostowe korzyści.
5. najprostszą zdecentralizowaną metodą wyrażania tożsamości, która jest wbudowana w infrastrukturę internetową, jest nazwa domeny.
Jako drugi poziom wyrażania tożsamości, każda domena zarządza własnym zestawem kont.
6. formularz "account@domain" jest zwięzły i obsługiwany przez szeroki zakres protokołów i schematów URI. Taki identyfikator jest oczywiście najbardziej powszechnie rozpoznawany jako adres e-mail.
7. dostawcy poczty e-mail są już de facto głównymi dostawcami tożsamości online. Bieżące Resetowanie hasła zazwyczaj pozwala przejąć kontrolę nad Kontem, jeśli możesz udowodnić, że kontrolujesz powiązany z nim adres e-mail.
8. sprawdzony protokół e-mail został zaproponowany, aby zapewnić bezpieczną metodę, opartą na kryptografii klucza publicznego, w celu usprawnienia procesu udowodnienia domenie B, że masz konto w domenie A.
W przypadku przeglądarek, które nie obsługują protokołu Verified Email (obecnie wszystkie), Mozilla udostępnia shim, który implementuje protokół w kodzie JavaScript po stronie klienta. W przypadku usług poczty e-mail, które nie obsługują protokołu Verified Email, protokół pozwala stronom trzecim działać jako zaufany pośrednik, potwierdzając, że zweryfikowały własność użytkownika konta. Nie jest pożądane posiadanie dużej liczby takich stron trzecich; ta zdolność ma na celu jedynie umożliwienie ścieżki uaktualnienia, i jest znacznie preferowane, aby usługi e-mail dostarczały te twierdzenia same. [12]}Mozilla oferuje swoją własną usługę, aby działać jako zaufana strona trzecia. Dostawcy usług (tj. strony ufające) wdrażający protokół zweryfikowanych wiadomości e-mail mogą zdecydować się zaufać twierdzeniom firmy Mozilla lub nie. Usługa Mozilli weryfikuje własność kont użytkowników za pomocą tradycyjny sposób wysyłania wiadomości e-mail z linkiem potwierdzającym.
9. usługodawcy mogą oczywiście oferować ten protokół jako opcję oprócz innych metod uwierzytelniania, które chcieliby zaoferować.
10. dużą zaletą interfejsu użytkownika jest "selektor tożsamości". Kiedy użytkownik odwiedza witrynę i decyduje się na uwierzytelnienie, jego przeglądarka pokazuje mu wybór adresów e-mail ("osobisty", "praca", "Aktywizm polityczny" itp.) mogą posłużyć do identyfikacji siebie na stronę.
11. kolejną dużą korzyścią dla interfejsu użytkownika jest pomoc przeglądarce dowiedzieć się więcej o sesji użytkownika – kto jest zalogowany jako obecnie, przede wszystkim-więc może wyświetlać to w przeglądarce chrome.
12. ze względu na rozproszony charakter tego systemu, unika blokady do głównych stron, takich jak Facebook, Twitter, Google, itp. Każda osoba może posiadać własną domenę, a zatem działać jako własna tożsamość dostawca.

Nie jest to ś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: uwierzytelniania obsługiwanego przez przeglądarkę.

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

Nazywam to pole atrapy (choć tego nie wymyśliłem, więc mi nie kredytuj).

W skrócie: musisz tylko wstawić to do swojego <form> i sprawdzić, czy jest puste w momencie walidacji:

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

Sztuką jest oszukać bota, aby myślał, że musi wstawić dane do wymaganego pola, dlatego nazwałem wejście "e-mail". Jeśli masz już pole o nazwie e-mail, że jesteś korzystanie należy spróbować nazwać pole obojętne coś innego jak "Firma", "Telefon" lub "emailaddress". Po prostu wybierz coś, o czym wiesz, że nie potrzebujesz i co brzmi jak coś, co ludzie normalnie uznaliby za logiczne, aby wypełnić formularz internetowy. Teraz Ukryj pole input za pomocą CSS lub JavaScript / jQuery-cokolwiek pasuje Ci najlepiej-po prostu Nie Ustaw wejście type na hidden albo bot na to nie wpadnie.

Podczas walidacji formularza (po stronie klienta lub serwera) sprawdź, czy twoje pole atrapy 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 pola atrapy (w moim przypadku o nazwie "email") i nie spróbuje go wypełnić. Tak więc wartość pola atrapy powinna być nadal pusta, gdy formularz został wysłany.

W przypadku bota: bot zobaczy pole o typie text i nazwie email (czy jak to nazwałeś) i logicznie spróbuje wypełnij go odpowiednimi danymi. Nie obchodzi mnie, czy stylizowałeś formularz wejściowy za pomocą fantazyjnego CSS, Programiści internetowi robią to cały czas. Niezależnie od wartości w polu atrapy, nie obchodzi nas to, o ile jest ono większe niż 0.

Użyłem tej metody na księdze gości w połączeniu z CAPTCHA i od tego czasu nie widziałem ani jednego spamu. Wcześniej używałem tylko rozwiązania CAPTCHA, ale ostatecznie spowodowało to około pięciu postów spamu co godzinę. Dodawanie pola atrapa w formularz przestał (przynajmniej do tej pory) pojawiać się cały spam.

Wierzę, że może być również używany w sam raz z formularzem logowania/uwierzytelniania.

Warning: oczywiście ta metoda nie jest w 100% niezawodna. Boty mogą być zaprogramowane tak, aby ignorowały pola wejściowe z zastosowanym do nich stylem display:none. Trzeba też pomyśleć o osobach, które używają jakiejś formy autouzupełniania(jak większość przeglądarek ma wbudowane!), aby automatycznie wypełnić wszystkie pola formularza dla nich. Równie dobrze mogą wybrać w górę pola.

Możesz również zmienić to nieco, pozostawiając pole atrapy widoczne, ale poza granicami ekranu, ale to całkowicie zależy od Ciebie.

Nie sądzę, że powyższa odpowiedź jest "błędna", ale istnieją duże obszary uwierzytelniania, które nie są poruszane (a raczej nacisk kładzie się na" jak wdrożyć sesje cookie", a nie na"jakie opcje są dostępne i jakie są kompromisy".

Moje sugerowane edycje / odpowiedzi to

• problem polega bardziej na konfiguracji konta niż sprawdzaniu hasła.
• stosowanie authenizacji dwuskładnikowej jest o wiele bezpieczniejsze niż sprytniejsze środki haseł szyfrowanie

• Nie próbuj implementować własnego formularza logowania lub przechowywania haseł w bazie danych, chyba że Zapisywane dane są bezwartościowe przy tworzeniu konta i generowane samodzielnie (czyli w stylu web 2.0, takim jak Facebook, Flickr itp.)

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

Pozwala to uniknąć konieczności posiadania "sesji" lub pliki cookie, ponieważ sama przeglądarka za każdym razem ponownie szyfruje komunikację. Jest to najbardziej "lekkie" podejście do rozwoju.

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 zaimplementować mechanizmów uwierzytelniania po stronie serwera - ten problem został rozwiązany i jest obsługiwany przez większość głównych przeglądarek. Nie używaj plików cookie. Nie przechowuj niczego we własnej ręcznie zwijanej bazie danych. Wystarczy zapytać, per żądanie, jeśli żądanie jest autentyczne. Wszystko inne powinno być obsługiwane przez konfigurację i zaufane oprogramowanie innych firm.

Więc ...

Najpierw mylimy początkowe założenie konta (z hasłem) z ponowne sprawdzenie hasła. Jeśli jestem Flickr i tworzenie witryny po raz pierwszy, nowy użytkownik ma dostęp do wartości zerowej (pusta przestrzeń internetowa). Naprawdę nie obchodzi mnie, czy osoba tworząca konto kłamie o swoim imieniu. If I am tworząc konto w Intranecie / Ekstranecie szpitalnym, wartość leży we wszystkich aktach medycznych, więc ja dbam o tożsamość ( * ) twórcy konta.

To jest bardzo, bardzo trudna część. tylko przyzwoitym rozwiązaniem jest sieć zaufania. Na przykład, dołączasz do szpitala jako lekarz. Tworzysz stronę internetową hostowaną gdzieś ze zdjęciem, numerem paszportu i kluczem publicznym, a wszystkie hashujesz kluczem prywatnym. Następnie odwiedzisz szpital i administrator systemu patrzy na twój paszport, widzi, czy zdjęcie pasuje do ciebie, a następnie hashuje stronę internetową / zdjęcie za pomocą klucza prywatnego szpitala. Od teraz możemy bezpiecznie wymieniać się kluczami i tokenami. Jak każdy, kto ufa szpitalowi (jest tajny sos BTW). Administrator systemu może również udostępnić klucz sprzętowy RSA lub inne uwierzytelnianie dwuskładnikowe.

Ale to jest dużo kłopotów, a nie bardzo web 2.0. Jest to jednak jedyny bezpieczny sposób na stworzenie nowe konta, które mają dostęp do cennych informacji, które nie są tworzone samodzielnie.

1. Kerberos i SPNEGO - mechanizmy pojedynczego logowania z zaufaną stroną trzecią-w zasadzie użytkownik weryfikuje przed zaufaną stroną trzecią. (NB to nie jest w żaden sposób nie można ufać OAuth)

2. SRP - rodzaj sprytnego uwierzytelniania hasłem bez zaufanej strony trzeciej. Ale tutaj wchodzimy w sfery " bezpieczniej jest używać dwóch czynników uwierzytelnianie, nawet jeśli jest droższe "

3. SSL po stronie klienta-daje klientom certyfikat klucza publicznego (wsparcie we wszystkich głównych przeglądarkach-ale rodzi pytania dotyczące bezpieczeństwa maszyny klienckiej).

W końcu jest to kompromis-jaki jest koszt naruszenia bezpieczeństwa a koszt wdrożenia bardziej bezpiecznych podejść. Pewnego dnia możemy zobaczyć odpowiednie PKI powszechnie akceptowane, a więc nie ma już własnych zwijanych formularzy uwierzytelniających i baz danych. Pewnego dnia...

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

Im szybciej stworzysz hasze, tym szybciej będzie działał każdy Tester brute force. Wolniejsze skróty spowolnią brutalne wymuszanie. Algorytm slow hash sprawi, że brutalne wymuszanie będzie niepraktyczne dla dłuższych haseł (8 cyfr+)

Dobry artykuł o realistycznym szacowaniu siły hasła to:

Dropbox Tech Blog "Blog Archive" Zxcvbn: realistyczne szacowanie siły hasła

Moja ulubiona zasada w odniesieniu do systemów uwierzytelniania: używaj haseł, nie haseł. Łatwe do zapamiętania, trudne do złamania. Więcej informacji: kodowanie horroru: hasła a hasła

Chciałbym dodać jedną sugestię, której użyłem, opartą na głębokiej obronie. Nie musisz mieć tego samego systemu auth&auth dla administratorów, co zwykli użytkownicy. Możesz mieć osobny formularz logowania na osobnym adresie URL, wykonując osobny kod dla żądań, które przyznają wysokie uprawnienia. Ten może dokonywać wyborów, które byłyby całkowitym bólem dla zwykłych Użytkowników. Jednym z takich, których użyłem, jest szyfrowanie adresu URL logowania dla dostępu administratora i wysyłanie adminowi nowego adresu URL. Zatrzymuje wszelkie ataki brute force w prawo z dala, ponieważ Twój nowy adres URL może być arbitralnie trudny (bardzo długi losowy ciąg), ale jedyną niedogodnością Twojego administratora jest link w wiadomości e-mail. Napastnik nie wie już, gdzie w ogóle wysłać wiadomość.

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

Odnośnie poing Część IV: Forgotten Password Functionality w pierwszej odpowiedzi chciałbym zwrócić uwagę na ataki czasowe.

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

Odnośnie formularza zapomnianego hasła, I dodam, że dobrym pomysłem jest wyrównanie czasów między udanymi i niezaspokojonymi zapytaniami z pewną funkcją opóźnienia.

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

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

• "w korporacyjnym, intra - ustawienie netto," większość, jeśli nie wszystkie z powyższych może nie mieć zastosowania!

Wiele korporacji wdraża strony internetowe "tylko do użytku wewnętrznego", które w praktyce są" aplikacjami korporacyjnymi", które zostały zaimplementowane za pomocą adresów URL. Te adresy URL mogą (podobno ...) być rozwiązywane tylko w ramach " wewnętrznej sieci firmy." (która sieć magicznie obejmuje wszystkie VPN-connected " road warriors.')

Gdy użytkownik jest obowiązkowo podłączony do wspomnianej sieci, jego tożsamość ("uwierzytelnianie") jest już [...] "definitywnie znane", podobnie jak ich pozwolenie ("upoważnienie") na robienie pewnych rzeczy ... na przykład ... "aby uzyskać dostęp do tej strony internetowej."

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

Z twojego punkt widzenia, po prostu wiesz o tym: że każdy kto legalnie ląduje na twojej stronie musi towarzyszyć [zmienna środowiskowa magicznie zawierająca ...] a " token."(tj. brak takiego znaku musi być natychmiastową podstawą 404 Not Found.)

Wartość tokena nie ma dla Ciebie sensu, ale jeśli zajdzie taka potrzeba, "istnieją odpowiednie środki", za pomocą których Twoja strona internetowa może "[autorytatywnie] zapytać kogoś, kto wie (LDAP... itd.) "o dowolnym i każdy(!) pytanie, które możesz mieć. Innymi słowy, robisz a nie korzystasz z jakiejkolwiek "domowej logiki."Zamiast tego pytacie o władzę i bezgranicznie ufacie jej werdyktowi.

Użyj OpenID Connect lub Dostęp zarządzany przez użytkownika .

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