Klucz
Głośne wpadki

Ostatnio głośno jest o wpadkach z hasłami w poważnych (wydawałoby się) serwisach:

 
To skłania do głębszej refleksji - jak zarządzać własnymi hasłami do setek serwisów i usług? Jak profesjonalnie trzymać hasła w aplikacjach webowych?
 
Dla użytkowników: jak bezpiecznie i wygodnie zarządzać własnymi hasłami?

Bezwzględnym wymogiem jest posiadanie innego hasła do każdego serwisu / usługi. W niedawnej aferze na forum 4chan, użytkownikom zagranicznego katolickiego serwisu randkowego zszargano dobre imię wśród najbliższych (w realu). Atakujący w imieniu użytkowników wysłali do ich najbliższych pocztę, gdzie Ci rzekomo przyznają się do skrajnych ekscesów seksualnych i chorób zakaźnych. Ci użytkownicy mieli takie same hasło w serwisie randkowym i w poczcie (lub np. na facebooku). Kupowano także w ich imieniu sprośne gadżety (to samo hasło do serwisu PayPal). Niedbając o hasła w Internecie, narażasz swoje dobre imię w realu.

Używaj menadżera haseł (np. bezpłatny KeePass dla Windows lub komercyjny 1Password na Macu). Taki program bezpiecznie zapamięta za ciebie setki różnych haseł, dzięki czemu będziesz mógł stosować inne hasło w każdym serwisie i usłudze. Co więcej, dobry menadżer haseł będzie Cię automatycznie logował do serwisów i usług, czyniąc posługiwanie się wieloma hasłami wygodniejszym niż ręczne posługiwanie się jednym hasłem. Dobry menadżer wygeneruje Ci także silne hasła zgodne z najlepszymi praktykami. Wystarczy, że zapamiętasz jedno główne hasło do bazy programu. Co więcej, baza haseł KeePass jest silnie zaszyfrowana, dzięki czemu możesz ją wygodnie przesyłać pocztą lub przenosić na kluczu USB.

Zapoznaj się z dobrymi praktykami tworzenia silnych haseł, albo - najlpepiej - powierz tą funkcję swojemu menadżerowi haseł. Dobre hasło nie może zawierać słów w żadnym języku, nie może zawierać faktów (np. dat), musi zawierać małe i duże litery, cyfry i znaki specjalne ("krzaczki"), i musi mieć w zależności od zastosowania przynajmniej 8-16 znaków.

Nigdy nie wysyłaj haseł ani innych wrażliwych danych pocztą. Wszystko co wysyłasz pocztą traktuj jako upublicznione. Pamiętaj, że poczta zasadniczo nie jest szyfrowana i każdy system / osoba pomiędzy nadawcą i odbiorcą potencjalnie może ją podejrzeć.

Szczególną troską otocz hasła do poczty. Pamiętaj, że przejęcie poczty oznacza przejęcie wszystkich innych kont, nawet jeśli masz do nich inne hasła. Dzieje się tak ze względu na powszechnie stosowane mechanizmy resetowania haseł  (atakujący sprawdzi, w jakich serwisach masz konta i zresetuje tam hasła).

Jeśli używasz do logowania klucza prywatnego, pamiętaj o silnym passphrase. Dla wygody warto używać wtedy agenta kluczy (np. pageant na Windows), dzięki czemu hasło podajesz tylko raz przy uruchomieniu agenta.

Odchodząc od komputera, zawsze zablokuj pulpit (Win+L na Windows), aby nikt nie miał okazji podejrzeć haseł, poczty i innych otwartych danych. Wyrób sobie dobry nawyk Win+L.

Dla programistów: jak profesjonalnie implementować obsługę haseł w aplikacjach webowych?

Przy rejestracji użytkownik powinien widzieć wskaźnik siły hasła, ostrzegający na czerwono przed słabymi hasłami. Jeśli użytkownik w ramach swojego konta będzie miał dostęp do wrażliwych danych osób trzecich, należy nie tylko poinformować o słabym, ale także wymusić silne hasło.

Hasło w żadnym scenariuszu nie może być wysłane pocztą. Każdą wiadomość przesłaną pocztą należy traktować jako upublicznioną, ponieważ protokoły pocztowe z reguły nie są szyfrowane. Należy zdać sobie sprawę, że wiadomości często idą otwartym tekstem i każdy system/osoba pomiędzy nadawcą i odbiorcą może je odczytać.

W bazie danych nigdy nie trzyma się haseł. Przechowuje się ich skróty kryptograficzne. Dzięki temu administratorzy bazy danych nie znają haseł użytkowników, a w razie kradzieży bazy, haseł nie znają również atakujący. Do stworzenia skrótów kryptograficznych pod żadnym pozorem nie można wykorzystywać własnej roboty algorytmów. Należy skorzystać ze sprawdzonych rozwiązań. Obecnie zaleca się SHA-2 lub bcrypt (wariant Blowfish). Słabszy, ale dopuszczalny jest SHA-1, używany powszechnie w takich protokołach jak PGP, SSL, SSH, TLS. Niedopuszczalny jest MD5.

Hasła muszą być solone przed utworzeniem skrótu kryptograficznego. Sól to losowy ciąg znaków, który dodaje się do hasła tuż przed utworzeniem skrótu z całości. Zabezpiecza to przed atakami typu bruteforce + rainbow tables. Rainbow tables to metoda ataku brute force z przygotowanym słownikiem skrótów popularnych haseł. Dzięki losowej soli, nasze skróty są inne, zatem gotowa tabela w żaden sposób nie usprawni atakującemu żmudnego ataku brute force.

Sól musi być indywidualna dla każdego użytkownika. Sól powinna być wielokrotnie dłuższa od typowego hasła (np. 40-znakowa).

W przypadku zgubionego hasła, użytkownik powinien otrzymywać link umożliwiający zmianę hasła. Zauważmy, że link daje czasowy dostęp do konta - dlatego powinien szybko wygasać, np. po 24h. Przy wyższych wymaganiach bezpieczeństwa ta metoda może być uzupełniona o dodatkowe pytanie "osobiste" lub weryfikację SMS-em.

Rejestracja i logowanie, a także wszystkie inne fragmenty serwisu gdzie przesyłane są wrażliwe dane, powinny być po HTTPS. Wszystko co poszło protokołem HTTP należy traktować jako upublicznione.

Pamiętajmy także o filtrowaniu logów aplikacji - nie można dopuścić do sytuacji, gdzie w ramach logowania parametrów żądania w logach znajdzie się login i hasło lub inne wrażliwe dane.

(naturalnie kontomierz.pl spełnia wszystkie powyższe zalecenia)

Podsumowanie

Stosowanie powyższych dobrych praktyk nie tylko radykalnie zwiększy Twoje bezpieczeństwo - da Ci także poczucie profesjonalizmu i kontroli nad swoją cyfrową tożsamością.


dodaj własny »

5 komentarze czytelników

  1. anonim

    "Sól musi być indywidualna dla każdego użytkownika."

    Nie musi być. Indywidualne sole stwarzają problem z ich przechowywaniem. najwygodniej byłoby w bazie danych, ale to rozwiązanie z oczywistych względów odpada. Musimy przechowywać te sole w pliku, przez co komplikujemy sobie procedurę rejestracji/logowania i tworzymy kolejną rzecz, o której bezpieczeństwo trzeba się martwić.

    Pojedynczą sól można za to łatwo przechowywać w kodzie skryptu. Jeśli jest dostatecznie długa, to jest również praktycznie nie do odgadnięcia. Atak bruteforce albo znajdzie krótszą kolizję, w której soli nie będzie, albo będzie potrzebował czasu mierzonego w latach na osiągnięcie sukcesu.

    10 września 2009 17:46

  2. anonim2

    Oczywiście, że sól można trzymać w bazie, tuż przy skrócie. To, że hacker zna sól niewiele mu pomaga

    13 września 2009 09:07

  3. wiaczesław

    anonim - sól nie musi być trzymana oddzielnie, w praktyce trzyma się ją właśnie w bazie.

    15 września 2009 10:59

  4. anonim

    Użytkownikom polecam stronę http://nowehaslo.pl. Dzięki tej stronie pamiętając tylko jedno hasło, mamy możliwość generowania nowych, bezpiecznych haseł do używanych serwisów.

    27 marca 2010 12:06

  5. hmm

    anonim ma rację jesli chodzi o trzymanie haseł w bazie. Uważam to za średnio bezpieczne. Sól znacznie komplikuje życie hackerowi, więc po co mu je ułatwiać jeśli zna sól.
    Ja obrałem metodę obupulną, mianowicie trzymam w bazie sól, każdy użytkownik ma swoją własną sól, oraz w pliku. Funkcja hashująca miesza obie sole z hasłem. W przypadku kradzieży bazy danych haker znając sól pierwszą nie wiele zrobi nie znając drugiej. Dużo czasu również straci zanim zjarzy, że coś jest nie tak i najprawdopodobniej porzuci bazę.

    18 czerwca 2010 11:39

Nowe zasady dotyczące cookies. Wykorzystujemy pliki cookies w celu świadczenia Państwu usług na najwyższym poziomie, w tym w sposób dostosowany do indywidualnych potrzeb. Korzystanie z witryny bez zmiany ustawień dotyczących cookies oznacza, że będą one zamieszczane w Państwa urządzeniu końcowym. Możecie Państwo dokonać w każdym czasie zmiany ustawień dotyczących cookies. Więcej szczegółów w naszej Polityce dotyczącej cookies