19:13
3/4/2018

A dokładnie 496845761 haszy udostępnionych przez haveibeenpwnd.com zostało już złamanych przez hashes.org i można tam hashe odwrócić, dzięki czemu uda się ustalić najpopularniejsze na świecie hasła.

Przypomnijmy, że lista 500 milionów haszy została stworzona na podstawie wycieków z różnych serwisów i zawiera też informację ile razy dane hasło się pojawia w różnych wyciekach. Po co udostępniono taką listę i dlaczego w formie hashy haseł a nie czystych haseł? Bo NIST zaleca sprawdzanie czy podawane przez użytkowników hasła (np. podczas zakładania konta) nie znajdują się w publicznie znanych wyciekach, a twórca nie chciał publikować gołych haseł, bo część z nich zawiera dane identyfikujące użytkowników.

Ta rada NIST o sprawdzaniu haseł w wyciekach jest trochę na wyrost, bo może się okazać, że gdyby chcieć zablokować możliwość użycia każdego hasła które jest w zbiorze 500 milionów haseł, które kiedyś skądś wyciekły, to użytkownik będzie zakładał konto przez kilkadziesiąt minut, denerwując się że dwudzieste piąte hasło, które podaje też nie może zostać użyte. Warto więc zachować rozsądek i odrzucać te hasła, które są bardzo popularne (bo po wycieku bazy, pewnie w pierwszej kolejności atakujący będzie je sprawdzał).

PS. Pamiętajcie że użycie takiego hasła jak ktoś inny, to nie jest tak duży problem, jak użycie takiego hasła jak ta sama osoba w innym serwisie. Przede wszystkim trzeba się więc skupić na tym, aby użytkownikom nie pozwalać na ustawienie w serwisie takiego hasła, jakie mają w innym miejscu — tylko że to zdecydowanie trudniej jest sprawdzić ;)

Przeczytaj także:

Ten wpis pochodzi z naszego linkbloga *ptr, dlatego nie widać go na głównej.
*ptr możesz czytać przez RSS albo przez sidebar po prawej stronie serwisu.

16 komentarzy

Dodaj komentarz
  1. “Przede wszystkim trzeba się więc skupić na tym, aby użytkownikom nie pozwalać na ustawienie w serwisie takiego hasła, jakie mają w innym miejscu ”
    Nie możesz ustawić takiego hasła, bo użytkownik TwojaStara!!111oneone użył go wcześniej ;)

  2. Heh, to może formularz z animacją spin.gif i info “chwileczkę” a w tle próba logowania do gmaila, yahoo i outlooka na wpisane dane? ;-]

  3. “Przede wszystkim trzeba się więc skupić na tym, aby użytkownikom nie pozwalać na ustawienie w serwisie takiego hasła, jakie mają w innym miejscu” – znaczy się jako administrator mam próbować logować się na hasła moich użytkowników na na google, fejsbuka, microsoft, popularne usługi mailowe itp? :-D

  4. Przede wszystkim trzeba skupić się na tym, żeby nie wtrącać się w hasła użytkowników.

  5. Przede wszystkim należałoby odejść od klasycznego loginu i hasła na rzecz bardziej wyrafinowanych metod, OAuth2 przykładowo, użytkownik nie potrzebuje dzięki temu 100 różnych haseł, a ty nie musisz potwierdzać tożsamości bo robi to za ciebie jeden z Providerów..

    • Zaczynij używać logowania fejsbukiem albo gmailem ;)

  6. Nie wiem, czy w przypadku moich stronek ma to jakiś sens martwienie się o te 500M hashy bo w nowych frameworkach szyfrowanie/hashowanie haseł razem z solą, to standard.

    • Nie chodzi o sprawdzenie czy można zdehashować hasło, ale czy użytkownik nie używa jakiegoś z listy najczęściej używanych które są jako pierwsze wykorzystywane przy bruteforce itp.

    • Nawet jeśli używa jakiegoś znanego hasła, to i tak hashe trzeba najpierw obliczyć, żeby porównać z hashem, i znaleźć sól, a to kosztuje, nawet dla hasha md5.

  7. Od czego jest NaCl (nie, nie native client)? (-; Admin powinien solić hasła i to wszystko. Ja pisząc programy NIGDY nie pozostawiam możliwości, że nie da się ustawić soli dla haseł, a jak ktoś coś końcowo odbiera ustawiam sól na przynajmniej 10 losowych znaków. Tak więc taka baza mało komu się przyda.

  8. Ok, pytanie do solących. Haslo plain text jest haszowane, plus posypane solą. Sól to wartość znana w momencie solenia, i musi być zapisana w bazie, gdzies obok hasza.
    Więc jesli ktoś nam podprowadzi baze, to chyba razem z solą ? Czy moje rozmumowanie jest poprawne ?

    • Sól nie siedzi w bazie, tylko w skrypcie konfiguracyjnym. Tak ma framework CakePHP.

    • Najpierw posypywane solą a potem hashowane :)

    • @Moneetor Sól siedzi w bazie. Pepper siedzi w konfiguracji. Celem Salt jest łamanie każdego hasła po kolei oraz to, żeby to samo hasło w bazie miało zawsze inną wartość.
      Celem pepper jest dodatkowe zabezpieczenie by hasła były jeszcze bezpieczniejsze jeżeli komuś uda się jedynie wyciągnąć dane z bazy nie podkradając jednocześnie kodu źródłowego.

    • Pomyliłem gałezie w wątkach: Maurycy: Nie wiem skąd ty bierzesz tą nomenklaturę. ale w konfigu od CakePHP pisze wyraźnie w komentarzu, że to sól a nie pieprz. Nie wiem, może w grach inaczej to nazywają, ale nie w CakePHP. Jakoś nie widziałem dodatkowej kolumny, którą tworzy ten framework, żeby wcisnąć do bazy sól jako taką. Chyba że hash wynikowy z posypanego solą hasła nazywasz wstawieniem soli do bazy. Jak ktoś szyfruje, zamiast hashować, to i po rozkodowaniu 1 hasła rzeczywiście znajdziesz sól razem z hasłem, ale do tego trzeba albo backdora, albo pobrania konfigu, albo superkomputerów, czyli środków nieosiągalnych dla przeciętnego haxiora. Osobiście uważam, że szyfrowanie hasła to jednak ułatwianie zadania włamywaczowi, bo hasła zawsze gdzieś tam można znaleźć, a hash to zawsze hash i nawet znając sól, wiesz, że musisz za każdym razem znaleźć kolizję a to wymaga nadal poważnych środków sprzętowych i to dla każdego hasła z osobna.

  9. Nie wiem skąd ty bierzesz tą nomenklaturę. ale w konfigu od CakePHP pisze wyraźnie w komentarzu, że to sól a nie pieprz. Nie wiem, może w grach inaczej to nazywają, ale nie w CakePHP. Jakoś nie widziałem dodatkowej kolumny, którą tworzy ten framework, żeby wcisnąć do bazy sól jako taką. Chyba że hash wynikowy z posypanego solą hasła nazywasz wstawieniem soli do bazy. Jak ktoś szyfruje, zamiast hashować, to i po rozkodowaniu 1 hasła rzeczywiście znajdziesz sól razem z hasłem, ale do tego trzeba albo backdora, albo pobrania konfigu, albo superkomputerów, czyli środków nieosiągalnych dla przeciętnego haxiora. Osobiście uważam, że szyfrowanie hasła to jednak ułatwianie zadania włamywaczowi, bo hasła zawsze gdzieś tam można znaleźć, a hash to zawsze hash i nawet znając sól, wiesz, że musisz za każdym razem znaleźć kolizję a to wymaga nadal poważnych środków sprzętowych i to dla każdego hasła z osobna.

Twój komentarz

Zamieszczając komentarz akceptujesz regulamin dodawania komentarzy. Przez moderację nie przejdą: wycieczki osobiste, komentarze nie na temat, wulgaryzmy.

RSS dla komentarzy: