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ć ;)

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.

Dowiedz się, jak zabezpieczyć swoje dane i pieniądze przed cyberprzestępcami. Wpadnij na nasz kultowy ~3 godzinny wykład pt. "Jak nie dać się zhackować?" i poznaj kilkadziesiąt praktycznych i przede wszystkim prostych do zastosowania porad, które skutecznie podniosą Twoje bezpieczeństwo i pomogą ochronić przed atakami Twoich najbliższych. Uczestnicy tego wykładu oceniają go na: 9,34/10!

Na ten wykład powinien przyjść każdy, kto korzysta z internetu na smartfonie lub komputerze, prywatnie albo służbowo. Wykład prowadzimy prostym językiem, wiec zrozumie go każdy, także osoby spoza branży IT. Dlatego na wykład możesz spokojnie przyjść ze swoimi rodzicami lub mniej technicznymih znajomych. W najbliższych tygodniach będziemy w poniższych miastach:

Zobacz pełen opis wykładu klikając tutaj lub kup bilet na wykład klikając tu.

20 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.

    • @Moneetor >Nie wiem skąd ty bierzesz tą nomenklaturę
      Z czytania regularnie Troy Hunta i Security.SE oraz pracowania 10 lat w web aplikacjach. Nie wiem co do dyskusji miał wnieść tekst o tym, że “w grach inaczej to nazywają” innego niż wycieczka osobista.

      >In cryptography, a pepper is a secret added to an input such as a password prior to being hashed with a cryptographic hash function. A pepper performs a similar role to a salt, but while a salt is stored alongside the hashed output, a pepper is not. [wiki/Pepper (Cryptography)]

      > In cryptography, a pepper is a secret added to an input such as a password prior to being hashed with a cryptographic hash function. A pepper performs a similar role to a salt, but while a salt is stored alongside the hashed output, a pepper is not. [wiki/Salt (Cryptography)]

      (a jeżeli nie ufasz wiki to Security Stack Exchange i jest tam dość pytań i odpowiedzi na temat tego jak trzymać hasła – to, że CakePHP coś źle nazywa to nie moja wina)

      Nie wiem też skąd Ci się wzięło “szyfrowanie” bo o tym w ogóle nie wspomniałem, ale tak, szyfrowanie jak pokazuje przykład wycieku haseł z Adobe jest to zły pomysł.

      Mówiąc krótko, CakePHP używa soli źle, w ich wykonaniu jest to po prostu pepper. Nie mówiac już o tym, że używajątylko jednego wykonania hasha (domyślnie sha1) więc koszt pracy na bruteforce jednego hasła jest komicznie niski, normalnie uruchamiasz funkcję hashującą kilkaset lub więcej razy by spowolnić proces łamania (google “hashing work factor”).

      Ale tak naprawdę jak używasz PHP to używasz password_hash() i password_verify() i wtedy się nie martwisz, że robisz coś źle bo sam ogarnia generowanie soli.

    • Fak, dopiero co wstałem i w zaspaniu w imię w poście powyżej wpisałem nie swoje imie tylko Moneetora, przepraszam.

  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.

  10. @Maurycy
    czy przez Security.SE miales na mysli https://security.stackexchange.com/ ?

    • Tak. Trzeba uważać co się czyta akurat ze względu na to, że jest to Stack Exchange network więc każdy może dać odpowiedź i każdy może ją zaplusować, natomiast w pytaniach gdzie jest więcej głosów lub odpowiadają ludzie z dużą reputacją ogólnie odpowiedzi mocno trzymają się kupy.

Odpowiadasz na komentarz K

Kliknij tu, aby anulować

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

RSS dla komentarzy: