7:59
12/7/2012

Formspring zdaje się być dużym i znanym serwisem z pytaniami i odpowiedziami — my, szczerze mówiąc, dopiero dziś usłyszeliśmy jego nazwę po raz pierwszy i normalnie nie poświęcilibyśmy mu artykułu na Niebezpieczniku (ot, kolejny nudny wyciek bazy), gdyby nie sposób w jaki doszło do włamania…

Jak wyciekły hashe?

Powód wycieku jest bardzo popularny: włamanie na maszynę developerską, co gorsza, podpiętą do bazy produkcyjnej (pamiętacie włamanie do Wykopu sprzed kilku lat?). Z bazy wyciągnięto 420 tysięcy haseł SHA-256 z losowym saltem i opublikowano je z zachętą do łamania na jednym z for poświęconych bezpieczeństwu.

Formspring przyznał się do włamania, wymusił (a nie poprosił, to plus) reset haseł wśród swoich użytkowników i obiecał przejść na mocniejsze hashe BCryptu. Chociaż zrobił to tylko na blogu, bo w e-mailu do użytkowników zbyt wielu szczegółów nie ma:

formspring email

formspring email

Tak czy inaczej, wszyscy chwalą postawę Formspring za szybką reakcję i użycie “mocnych hashy z saltem”.

Ciekawe te “mocne” hashe

Przyjrzyjmy się jednak tym “mocnym” hashom, które wyciekły… Dump hashy pojawił się na forum InsiderPro już 6 lipca — oryginalny wątek na forum przestał istnieć, ale jest cache Google.

InsidePro formspring hash

InsidePro formspring hash

Podobnie jak w przypadku wycieku hashy z LinkedIn i tym razem wraz z hashami nie podano loginów, ani innych danych identyfikujących konta. Warto natomiast podkreślić, że użytkownik, który wrzucił bazę online jest uczestnikiem tego forum od 2009 roku.

Co do samych hashy, to użyty do ich wygenerowania salt jest mocno dyskusyjny. Okazuje się, że jest to liczba z przedziału 00-99, a format hasha to:

sha256([00-99]+$hasło)

Po co “solisz” i hashujesz, programisto?

Hasła się hashuje i “soli” aby opóźnić (a nie uniemożliwić!) ich rozszyfrowanie przez atakującego. Ideą salta jest po pierwsze wydłużenie początkowego ciągu znaków (czyli hasła podanego przez użytkownika) wpadającego na funkcję skrótu tak, aby na wynikowym hashu nie można było przeprowadzić ataku znanego jako Rainbow Tables. Atak Rainbow Tables polega na wyszukaniu hasha w wyliczonej wcześniej tablicy hashy. Takie “tęczowe tablice” są dostępne do ściągnięcia w internecie dla różnych zestawów znaków (alfabetów) i zazwyczaj bezpłatnie można je pobrać dla ciągów o długości maksymalnie ok. 14 znaków (ale uwaga, chętni powinni przyszykować kilka wolnych terabajtów na dysku).

Drugi z powodów użycia salta to chęć uzyskania unikalnego hasha dla wszystkich użytkowników, którzy wybrali sobie takie samo hasło. W przypadku salta Formspringu, który może przyjąć tylko 100 wartości, atakujący ma dość proste zadanie: wyliczenia nie jednego “słownika” wszystkich możliwych hashy popularnych haseł, a 100 takich słowników (każdy będzie się zaczynał od innej liczby z przedziału 00-99).

Przejście Formspringa na BCrypt zdecydowanie dobrze im zrobi, bo ich obecna implementacja “bezpiecznych hashy” zdecydowanie nie jest najlepsza. Aha, Formspring udzielił też swoim użytkownikom genialną wskazówkę:

Other Useful Tips:
Don’t put your email address, address or phone number in your Formspring profile

To po cholere ich o to pytają i dają możliwość wpisania tego typu danych w swoim serwisie? :-)

Przeczytaj także:


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.

30 komentarzy

Dodaj komentarz
  1. Chociaż dobrze, że forma hasha to sha256([00-99]+$hasło).

    • no chyba nie doczytales. niezbyt dobrze. ale masz racje, bo na pewno lepej niz w plaintext ;]

    • LOL – najpierw go tyrasz, a potem przyznajesz rację…

  2. może mają jakieś profile, i strony typu ‘O sobie’. Trudno chyba byłoby moderować wszystkie tego typu profile w poszukiwaniu adresów email, numerów tel czy adresu zamieszkania.

    Nie koniecznie musi byc to pole “Adres email: “

  3. A mój kolega z pracy ma koszulkę Niebezpiecznika i nie soli hashy haseł. Kuba, ogarnij się!

    • Może zbiera próbki haseł w plaintekście do brute-forcea na jakiś znany serwis?

  4. Nie powinno się za dużo solić, sól szkodzi.

  5. @Niebezpiecznik: może to już najwyższy czas na dział “Artykuły”? Bardzo chętnie bym czytał wasze porady na temat bezpieczeństwa (m.in. “porady kucharskie”) :)

  6. @malan Marzenie… Jeśli chcesz się coś nauczyć to Piotr zaprasza Cie na niebezpiecznikowe szkolenie… this is business

    • Ale dział giełda pomysłów (Loża Szyderców) jako miejsce, gdzie różni programiści, pasjonaci dyskutowali by o technologiach bezpieczeństwa i ogólnie pojętego programowania powinien mieć racje bytu.

      Najlepiej w formie:
      pomysł, ocena realności zaistnienia(wykonania), próba implementacji, opinie i testy.
      Licencja wolna oczywiście.

      Jako że Niebezpiecznik od pewnego czasu jest opiniotwórczy, a i grono ludzi, którzy go odwiedzają, jest szerokie, każdy mógłby dodać jakąś cegiełkę ze swojej dziedziny.
      Marketingowo wyjdzie to na korzyść Niebezpiecznika, po pierwsze reklama in situ, patronat merytoryczny, a dodatkowo będzie on monitorował trendy w myśleniu środowiska IT, a zatem pentesty w wykonaniu Niebezpiecznego Teamu, byłyby silnie skorelowane z jakimiś stereotypami, które wyszły by w praniu w tym dziale.
      Dzięki temu też, można mieć punkt odniesienia względem którego można jakiś bardziej obiektywny ranking bezpieczeństwa firm wprowadzić, oczywiście we własnym zakresie, nie publicznie.

      Poza tym burza mózgów, czasem i bluzgów (tak trolle to taki szum, przyczynek do rezonansu stochastycznego w dziedzinie kreatywności), przynosi wymierne korzyści całemu środowisku IT.

      A ten blog, jak już wspominałem, jest wystarczająco poczytny by mieć wpływ na masy.

      Choć faktycznie taki dział, wymaga pewnych zmian w samym blogu, ale to oczywiste.
      I moim zdaniem po okresie wdrożenia i inkubacji, może mieć popularność równie dużą co ciekawostki ze świata bezpieczeństwa prezentowane teraz.

      Ps. Tak tak, nadal zbieram krakersy ;->

    • @subiektywny_gosc tak, zróbcie sobie forum dla haker00w :)

  7. Mam pytanie dotyczące soli. Czy dobrym pomysłem jest tworzenie jej na podstawie loginu? Czyli hash byłby następujący sha256(sha256($login).$haslo).

    • Ja generuję sól używając jakiś ukrytych danych (np. emaila) i ciągu losowych znaków.

    • W dziedzinie unikalności w bazie to faktycznie dobry pomysł.
      Ale w dziedzinie bezpieczeństwa niestety za słaby.
      Atakujący przeważnie login zdobywają nim zaczną coś kombinować z hasłem.
      Chociażby socjotechniką jakąś.
      Ale jak posolisz to co napisałeś, to już będzie całkiem nieźle ;->
      Albo zabawa soloną maską ;-> na całości przed hashowaniem.
      Przy założonej entropii maski.

    • Po pierwsze tworzenie hasha z hasha to przekleństwo. Rozszyfrujesz go szybko, bo długość “textu” ma stałą długość (i tylko określone znaki). Tu nawet brute force długo nie potrwa.

      Po drugie wykorzystanie loginu jako soli to też kiepskawy pomysł. Wszystko co randomowe jest lepsze.

      Po trzecie (to już bardziej skomplikowane) zwiększa się szansa na podstawienie innego ciągu znaków, który ma taki sam hash.

    • OK. Dziękuję za odpowiedź.

    • Solenie loginami to zły pomysł. Dobra sól powinna się zmieniać przy każdej zmianie hasła, być maksymalnie losowa i mieć sporą długość (dla hashy typu SHA, bo dla bcrypt może mieć mniej). Chodzi o to, żeby zminimalizować prawdopodobieństwo, że są dla tej soli wygenerowane lookup tables. Do tego sól powinna być trzymana w innym miejscu niż hash hasła – na przykład w innej, oddzielnie backupowanej, bazie danych.

    • Hmm a może zamiast loginu pobrać datę utworzenia konta wtedy indywidualność gwarantowana.

  8. Formspring jest całkiem popularny w Polsce, dziwne, że nie słyszeliście :)

  9. Jak zdobyć losowe loginy i hasła kont pocztowych?

    • Oj tam oj tam…
      Losowość u przeciętnego zjadacza chleba, nie świadomego niebezpieczeństwa,
      kończy się na posiadaniu jednego hasła do 20 różnych serwisów.
      Często powiązanych w jakiś sposób ze sobą.
      A któryś z serwisów zawsze ma słabsze zabezpieczenia i słabiej soli niż inni,
      żeby nie powiedzieć, że czasami coś pieprzy…

  10. hash z hasha sprawia, AFAIK, że atakujący będzie musiał dłużej brutować (2 razy sha256 zamiast jednego razy).

    Co zwiększa bezpieczeństwo hasha.

    • Masz racje, ale tylko w przypadku łamania metodą pełnego przeglądu.
      Jak piszą koledzy wyżej, w związku z tym, że nie wydłużasz w ten sposób hasha to trudność problemu rośnie nieznacznie, a prawdopodobieństwo kolizji wręcz przeciwnie.

      Pozdrawiam

    • @M4tek święta prawda, jak nie wydłużymy hasha, bo ma ograniczoną pojemność.

      Ale w sumie jakby używać metody kombinowanej, gdzie w bazie przechowywany jest nie tyle hash, sole i maski, co dodatkowo sam hash zamaskowany kilkoma “losowymi” danymi opisanymi jakimiś parametrami zaszytymi w kodzie poza bazą, plus parametry również pseudo losowe i solone (już w bazie np. zakodowane, stylizowane na inny hash), określające który algorytm kombinowany dla danego usera jest tym faktycznym.

      Czasami już sama stylizacja soli, masek na hashe odpowiednim przekodowaniem, przy włamie może namieszać, ale nigdy wprost nie podpisywać co jest co, bo jak ktoś dorwie roota na bazie, to sami wiecie. Już lepiej to sobie na karteczce opisać, czym co jest ;->
      Zaciemnianie może i jest nie ideowe, ale może dodać te kilka minut po włamie, na reakcję.

      Doklejenie, czy raczej wmieszanie, czegoś równie dużego co hash, do(w) hasha ale o zmiennej wielkości (i entropii) (minimum, moim zdaniem, wielkości hasha) dla każdego usera. Plus jakieś zaszyfrowanie tylko maskowanych bitów w takim tworze, gdzie szyfrowanie i maskowanie może być kaskadowe i inne dla każdego usera.

      Faktycznie narzut obliczeniowy może być dużo większy, ale czy aż tak znacząco, by nie rozważyć takiej kombinowanej metody ?? Optymalizacje i zewnętrzne niskopoziomowe dedykowane aplikacje, jako moduły, mogą sobie poradzić w trymiga.

  11. Przepraszam, ale jak sprawdzacie poprawność podanego hasła, skoro zostało posolone LOSOWYM ciągiem i zahashowane?

    • salt nie jest tajny. salt jest jawny (algorytmicznie lub po prostu przechowywany w bazie)

  12. […] tydzień włamań i wycieków trwa. Po wycieku 430 000 hashy z serwisy Formspring oraz 450 000 haseł z Yahoo i miliona rekordów użytkowników forum Androida, przyszła kolej na […]

  13. […] również w bazie danych są one trzymane jawnym tekstem (a to oznacza spory kłopot przy wycieku bazy, np. poprzez popularne ataki SQL injection albo włamanie na serwer deweloperski) […]

  14. […] PS. Programisto, 3 znakowa sól to niezbyt dobre podejście do bezpieczeństwa. Sól ma zapobiegać atakom przy pomocy tablic tęczowych, a więc powinna być tak długa, żeby hasło połączone z solą nie miało długości krótszej niż dostępne tablice tęczowe… Więcej o bezpiecznym podejściu do przechowywania haseł pisaliśmy w tym artykule. […]

  15. […] w serwisie zgodnie z dobrymi praktykami. Opisaliśmy je w tym tekście — wyjaśniając dlaczego “soli się” hasła użytkowników, i że są lepsze metody “kryptograficznej” ochrony haseł. A jeśli chcesz się […]

Twój komentarz

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

RSS dla komentarzy: