20:40
6/5/2018

Na przestrzeni ostatnich kilku dni dwa duże serwisy Twitter i GitHub zaliczyły wpadki związane z niepoprawnym przechowywaniem haseł swoich użytkowników. A dokładniej — oba serwisy przyznały, że przechowywały hasła użytkowników jawnym tekstem, czyli bez szyfrowania. Na szczęście tylko w logach do których ponoć mało kto z pracowników zaglądał…

GitHub logował zmieniane hasła

Najpierw o wycieku haseł poinformował GitHub. 1 maja rozesłał taką wiadomość e-mail do użytkowników:

Temat: [GitHub Security] Please reset your password

Hi there,
During the course of regular auditing, GitHub discovered that a recently introduced bug exposed a small number of users’ passwords to our internal logging system, including yours. We have corrected this, but you’ll need to reset your password to regain access to your account.
GitHub stores user passwords with secure cryptographic hashes (bcrypt). However, this recently introduced bug resulted in our secure internal logs recording plaintext user passwords when users initiated a password reset. Rest assured, these passwords were not accessible to the public or other GitHub users at any time. Additionally, they were not accessible to the majority of GitHub staff and we have determined that it is very unlikely that any GitHub staff accessed these logs. GitHub does not intentionally store passwords in plaintext format. Instead, we use modern cryptographic methods to ensure passwords are stored securely in production. To note, GitHub has not been hacked or compromised in any way.
You can regain access to your account by resetting your password using the link below::
https://github.com/password_reset
If you have any lingering questions or concerns about this, don’t hesitate to let us know. You can reach us by emailing support@github.com or by using our contact form:
https://github.com/contact
Thanks,
GitHub Support

W przypadku GitHuba, wyciek dotknął niektórych użytkowników (tych, którzy dokonywali resetu hasła) i polegał na logowaniu hasła jawnym tekstem w pliku, który nie był publicznie dostępny i który nie został wykradziony. Ale ponieważ niektórzy pracownicy GitHuba mieli do niego dostęp, serwis na wszelki wypadek wymusił zmianę haseł wśród osób dotkniętych “wyciekiem”. I to należy docenić. Bardzo odpowiedzialna postawa!

Co ciekawe, zawinił błąd w mechanizmie antyspamowym, który zliczał wywołania funkcji resetu hasła. Błąd został wykryty wewnętrznie a wykrycie — w przeciwieństwie do tego co sugerowali niektórzy internauci — nie miało nic wspólnego z żadnymi procesami pre-GDPR-owymi.

Monitorowanie zdarzeń resetu hasła ma wiele zalet. W ten sposób można ujawnić m.in. wycieki baz danych lub nieuprawniony dostęp. Tę sztuczkę zdradzam od lat uczestnikom szkolenia Atakowanie i Ochrona Webaplikacji. Ciekawych tricków na podniesienie bezpieczeństwa webaplikacji jest oczywiście o wiele więcej. Zainteresowanych zapraszam na najbliższe terminy tego szkolenia, które odbędą się 14-15 maja w Warszawie, 17-18 maja w Krakowie, 24-25 maja w Gdańsku i 18-19 czerwca we Wrocławiu. Po wybraniu dogodnego terminu miejsce można poprzez formularz na tej stronie, a z opiniami uczestników ostatnich terminów można zapoznać się tutaj.

Twitter miał podobny błąd

Dwa dni po wpadce GitHuba, do podobnej wpadki przyznał się Twitter… Użytkownicy po zalogowaniu się na swoje konta zobaczyli taki komunikat (dostali go też e-mailem):

Hi @niebezpiecznik,
When you set a password for your Twitter account, we use technology that masks it so no one at the company can see it. We recently identified a bug that stored passwords unmasked in an internal log. We have fixed the bug, and our investigation shows no indication of breach or misuse by anyone.
Out of an abundance of caution, we ask that you consider changing your password on all services where you’ve used this password. You can change your Twitter password anytime by going to the password settings page.
About The Bug
We mask passwords through a process called hashing using a function known as bcrypt, which replaces the actual password with a random set of numbers and letters that are stored in Twitter’s system. This allows our systems to validate your account credentials without revealing your password. This is an industry standard.
Due to a bug, passwords were written to an internal log before completing the hashing process. We found this error ourselves, removed the passwords, and are implementing plans to prevent this bug from happening again.
Tips on Account Security
Again, although we have no reason to believe password information ever left Twitter’s systems or was misused by anyone, there are a few steps you can take to help us keep your account safe:
1. Change your password on Twitter and on any other service where you may have used the same password.
2. Use a strong password that you don’t reuse on other services.
3. Enable login verification, also known as two factor authentication. This is the single best action you can take to increase your account security.
4. Use a password manager to make sure you’re using strong, unique passwords everywhere.
We are very sorry this happened. We recognize and appreciate the trust you place in us, and are committed to earning that trust every day.
Team Twitter

W przypadku Twittera szczegóły odkrycia błędu nie są znane. Ale każdy kto pracował przy tworzeniu aplikacji webowej wie, jak łatwo o wpadkę tego typu. Wystarczy podczas logowania “załączyć” niepotrzebnie tryb DEBUG i już w logi lecą rzeczy, które nie powinny i — co równie często spotykane — o takiej pomyłce zespół zazwyczaj dowiaduje się przez przypadek i pod długim czasie.

Sam znam historię, jak to jeden z polskich banków przesyłał miesiącami do swojego partnera pełne dane (logi z transakcji kartowych) zupełnie niepotrzebnie. Ot, pomyłka.

Nie ma powodu do paniki, ale…

Wpadka Twittera i Githuba to przeoczenie o minimalnym ryzyku dla użytkowników tych serwisów, ale i dobra okazja, aby przypomnieć, że:

  • Hasła w większości przypadków są hashowane dopiero po stronie serwera (backendu), a wiec — jak to pięknie pokazał przypadek GitHuba — serwis może “złapać” niezahashowane jeszcze hasło i je zapisać, chociaż później będzie je w bazie przechowywał w poprawny, trudny do złamania sposób (tu: bcrypt). Dlatego nie warto ufać twórcom serwisów, że wszystko robią dobrze i należy stosować się do rady z punktu poniżej.
  • Komunikaty takie ja ten od Twittera czy GitHuba już od dawna nie powinny na nikim robić wrażenia. Hasła wyciekały, wyciekają i będą wyciekać i przynajmniej czytelnicy Niebezpiecznika powinni je już od dawna mieć wszędzie ustawione jako unikatowe ciągi. Takie podejście, w przypadku wycieku, uniemożliwi przejęcie innych kont ofiary niż to, którego hasło ujawniono. Ustawienie różnych haseł do różnych serwisów to najważniejsza “cyberporada”. Serio.

Co ciekawe, chociaż serwisy zachowały się odpowiedzialnie, informując czytelników o swoich przeoczeniach i nie zamiatając sprawy pod dywan, to większość odbiorców e-maili z ostrzeżeniami wyraża opinię raczej pogardliwą (w stylu: “co za łosie, trzymali hasła plaintekstem, jak tak można!!11one!!1!“. Chyba tylko ludzie z branży dostrzegają “gest” i profesjonalizm takich akcji informacyjnych. Trochę szkoda, że użytkownicy jeszcze nie widzą różnic w prośbach o zmianę hasła wynikłych z wewnętrznych audytów (plus) a wycieków/kradzieży danych (minus).

“Dajcie spokój, ustawianie unikatowych haseł to za duży wysiłek!”

Prawie zawsze to słyszę, kiedy podczas prowadzenia naszych cyberwykładów w różnych polskich firmach rekomenduję pracownikom ustawianie unikatowych haseł nie tylko do firmowych ale i do prywatnych usług.

Bo oczywiście — w przypadku wielu kont pojawia się problem: Jak spamiętać wszystkie te unikatowe hasła? Nie zalecam układania haseł wedle algorytmu, np. MojeTajeHasloDoGitHuba2018!, bo ktoś domyśli się jakie ustawiłeś dla Twittera. Po prostu skorzystaj z managera haseł, np. KeePassa i generuj w nim losowe ciągi znaków dla każdego z serwisów w którym rejestrujecie konto.

KeePass (i KeePass XC na macOS) jest wygodny, bo sam potrafi uzupełniać hasła podczas logowania (trzeba doinstalować rozszerzenie do przeglądarki lub skorzystać z modułu tzw. AutoType). Korzystanie z KeePassa wymaga zapamiętania tylko jednego hasła — tego do KeePassa. KeePassa uważam za lepszego od reszty managerów haseł, bo ma otwarty kod źródłowy, nie korzysta z “chmury” i posiada wersję na każdy system operacyjny, także na iPhona.

No ale — jak czujny czytelnik zapewne już dawno zauważył — stosowanie unikatowych haseł rozwiązuje problem z nieautoryzowanym dostępem do innych kont ofiary, ale nie rozwiązuje problemu nieautoryzowanego dostępu do tego konta ofiary z którego to hasło wyciekło. Ten problem akurat nie dotyczy ani GitHuba, ani Twittera. Oba serwisy wspierają dwuskładnikowe uwierzytelnienie, czyli wymóg podania podczas logowania nie tylko hasła (coś co znam i coś co może wyciec i ktoś inny też będzie to znał), ale również czegoś dodatkowego, co tylko właściciel konta posiada (idealnie fizycznie przy sobie).

    W przypadku GitHuba warto pod konto podpiąć token U2F, np. YubiKey (o tym dlaczego tylko tokeny U2F chronią przed phishingiem przeczytacie tutaj).

    Twitter niestety nie wspiera kluczy U2F (buuu!), ale z kontem można skojarzyć aplikację generującą jednorazowe kody dostępu (tzw. OTP), korzystając ze specjalnej aplikacji np. Google Authenticator lub Authy (ta druga jest lepsza, bo potrafi wykonać kopię bezpieczeństwa “seedów”, co doceni każdy, komu kiedyś ukradną telefon albo go zepsuje). I chociaż to prawda, że te kody da się wykraść ofierze poprzez phishing, to lepsze to niż nic. Zresztą w kontekście tego artykułu mówimy o zabezpieczeniu się przed wyciekiem haseł, a nie ochroną przed phishingiem (to bardziej skomplikowany temat).

Czy można zapisywać hasła w przeglądarce?

Na koniec poruszę jeszcze jedną kwestię. Jednym z najczęściej zadawanych po moim wykładzie “Jak nie dać się zhackować?” pytaniem jest to:

Czy zapamiętywanie haseł w przeglądarce jest bezpieczne?

Odpowiedź nie należy do najłatwiejszych…

Zapisywanie haseł w przeglądarce jest dobre, bo pomaga wykryć atak phishing (jeśli hasło samo się nie “autouzupełni” to powinno to dać do myślenia ofierze). Jeśli zapamiętywane w przeglądarce hasło jest unikatowe, to pomoże to też w sytuacji której dotyczy artykuł — jego wyciek/kradzież nie narazi innych kont ofiary na przejęcie. Ale oczywiście — zapamiętywanie haseł może się też okazać złym pomysłem, jeśli ktoś uzyska dostęp do komputera (np. fizycznie lub poprzez infekcję złośliwym oprogramowaniem). Wtedy w znakomitej większości przypadków będzie on w stanie podejrzeć hasła zapisane w przeglądarce (w KeePassie i innym managerze haseł też). No ale jak ktoś uzyska dostęp do twojego komputera, to jak to mawiają,

to nie jest już twój komputer

Nie jest celem managera haseł (osobnego czy wbudowanego w przeglądarkę) ochrona przed tym zagrożeniem. Te rozwiązania powstały by chronić przed częstszym problemem — wyciekiem haseł z serwisów internetowych i użyciem jednego znanego hasła danej osoby do dostępu do jej innych kont, gdzie hasło jest takie samo.

Podsumowując, dla większości osób trzymanie haseł w przeglądarce to dobra decyzja. Byle tylko były one różne do różnych serwisów. To właśnie unikatowość haseł jest najważniejsza.

Takie proste, sensowne i ważniejsze sprawdzone w boju rady jak te powyzej stanowią podstawę mojego wykładu “Jak nie dać się zhcakować?“. Poruszam w nim nie tylko kwestię bezpieczeństwa haseł czy ochrony przed phishingiem lub złośliwym oprogramowaniem. Pokazuję jak bezpiecznie komunikować się z bliskimi, chronić przed internetowym złem swoje dzieci (lub rodziców i dziadków ;) i jak robić zakupy w internecie tak, aby nie stracić pieniędzy, nawet jeśli kontrahent okaże się oszustem. Poza prostymi do zrozumienia poradami dzielę się też listą przydatnych serwisów internetowych i darmowymi programami które ułatwiają zabezpieczenie komputera, smartfona i cyfrowej tożsamości. Wpadnij posłuchać :) Wykład w maju odbędzie się w Warszawie, Krakowie, Łodzi i Gdańsku (a po wakacjach także we Wrocławiu). Z pełną agendą zapoznasz się i miejsce zarezerwujesz na tej stronie.

Przeczytaj także:

34 komentarzy

Dodaj komentarz
  1. Cytat z instrukcji obsługi jednego systemu finansowo-księgowego: “zaklejoną kopertę z hasłem zaleca się przechowywać w bezpiecznym miejscu, np. w sejfie”. :)

  2. KeePass XC oraz KeePass X są dostępne także dla Linuksów.

  3. hmmm… wiem, że KeePass jest open source, ale czy ktokolwiek, kiedykolwiek właściwie zrobił mu audyt bezpieczeństwa?

  4. Dziwne to troche, że 2 duże portale przyznają się do tego samego błędu w tym samym czasie. Być może to jest poprostu nowa ściema na wyciek haseł i wymuszenie resetu bez konsekwencji utraty wizerunku, albo mają ruskiego kreta w teamie co im w kodzie namieszał.

    Co do managera haseł to wbudowany w OS X /ios keychain w pełni wystarcza – hasła w chmurze są hashowane, więc nie ma się co martwić o wyciek … no chyba, że to ten programista z Twittera/githuba odpowiada za logi

    • Obstawiam, że korzystały z tego samego programu/skryptu do tworzenia logów. Jak wszyszło powiadomienie o wykrytej podatności i aktualizacja, to obie zareagowały identycznie

    • Nie są hashowane. Mylisz hashowanie z szyfrowaniem.

  5. Co z tego, że mam super tajne hasło skoro jakaś strona internetowa przechowuje hasła jawnym tekstem, lub jakiś pracownik na wszelki wypadek zrobił sobie kopię zapasową wszystkiego co się da.

  6. Może to głupie pytanie ale co da przejęcie komputera skoro plik bazy KeePass-a jest zabezpieczony mocnym szyfrowaniem ?

    • To, że keylogger je złapie podczas pierwszego wpisania :)

    • W KeePass masz możliwość ustawić logowanie do bazy w trybie bezpiecznego pulpitu, który powinien zapobiec przechwyceniu hasła przez keyloggery. Do tego można zastosować program KeyScrambler.

    • Wciaz jednak mozesz sniffowac hasla przesylane do serwisow. Generalnie na kazde takie zabezpieczenie jak masz mozliwosc wykonania kodu po stronie ofiary znajdzie sie obejscie, niestety…

  7. Jak najlepiej synchronizować bazę keepasa pomiędzy urządzeniami ?

    • Mozesz przez iCloud jesli ufasz Apple, dropbox jesli ufasz dropboksowi, albo Google Drive jesli ufasz Google. Plik z baza jest zaszyfrowany wiec nawet jak wpadnie w niepowolane rece, haslo obroni go przed nieautoryzowanym dostepem, jesli jest wystarczajaco silne.

    • Polecam syncthing! Na każdą platformę: https://syncthing.net/

    • Ważna sprawa… Każdy z tych serwisów przechowuje wersje plików. Jeśli więc zmieniamy hasło do bazy keepass warto skasować starsze wersje. Jeśli trzymamy kopie pliku keepass jako backup w chmurze to nie trzymajmy hasła do usługi chmurowej tylko w keepass. Strata urządzenia źródłowego może kosztować nas utrata dostępu do chmury a tym samym również do bazy keepass.

  8. Czemu hasła nie są hashowane po stronie klienta? Czy to nie powinien być standard? Sprawdzenie czy hasło nie jest zbyt krótkie itp też można zrobić po stronie klienta, o ile w tym tkwi powód tego rozwiązania.

    • Hashowanie hasła po stronie klienta ma sens tylko i wyłącznie jeśli później ten hash jest traktowany jako zwykły ciąg znaków i hashowany raz jeszcze po stronie serwera (tym razem porządnie). Jedyne co to zmienia to długość ciągu przesyłanego od klienta do serwera autoryzacji.

      Pełne hashowanie po stronie klienta umożliwia jedynie atakującym na wykradzenie listy użytkowników (podpowiedź: sól musi byc losowa i różna dla różnych kont)

    • Bo hashowanie bez soli (SALT) jest słabym hashowaniem, a z kolei ujawnianie soli (co musiałoby mieć miejsce przy hashowaniu po stronie klienta) jest równie kiepskie :)

    • @Adam:
      Sól może być publiczna?

      Jak ktoś Ci ukradnie bazę danych to będzie też w niej sól, a przecież ma ona zabezpieczać w momencie ataku.

    • Z tym haszowaniem po stronie klienta, to różne aplikacje różnie mają… u nas standardem jest potraktowanie hasła paroma trywialnymi funkcjami szyfrującymi, potem zahaszowanie z ziarnem “publicznym”, przesłanie przez internety, a po stronie serwera jeszcze dobranie do tego hasza ziarna “prywatnego” i jeszcze raz zahaszowanie, przy czym nie jest też kwestią trywialną jak zostanie przekształcony wcześniej hasz i ziarno. Serwer nigdy na żadnym etapie procesu nie zna prawidłowego hasła czystotekstowo, sam zaś moduł weryfikacji przesłanego hasza z tym trzymanym w bazie kont i ziarnem to skompilowany moduł PHP wywoływany jak pojedyńcza funkcja ;)

    • @Lukasz032

      ile razy by nie tłumaczyć ludziom żeby nie wymyślali własnego crypto, to i tak to zrobią. Ehhh.

    • @Jan Kowalski – sól może nie tyle jest (może być) publiczna, ale nie jest sekretem, a jej rola zabezpieczająca nie polega na jej ‘tajności’. Natomiast co jest istotą soli, to jak wspomniał @Tchórz Anonim, powinna być ona unikalna i inna dla każdego użytkownika. Sól służy do tego, aby w momencie wycieku bazy atakujący, który uzyskał dostęp i jest w posiadaniu dwóch wartości: [hash(password + salt), salt] dla każdego rekordu, nie był w stanie w łatwy i wydajny sposób zreversować (np. przy pomocy rainbow table, RT) wszystkich tych par. Budowanie RT jest dość kosztowne, a jeśli każdy rekord zawiera unikalną sól, to każdy z nich wymaga zbudowania osobnej RT. Po prostu unikalna sól sprawia, że RT trzeba przebudowywać dla każdego rekordu, albo trzeba zbudować tablicę tak wielką, żeby zawierała wszystkie kombinacje hash(password + salt).
      Powyższy mechanizm implikuje też konieczność zmiany soli przy każdej zmianie hasła – bo jeśli atakujący poznał twój posolony hash i twoją sól, i zdołał jednak zbudować przeznaczoną specjalnie dla twojego rekordu RT, to zmiana samego hasła i posolenie go tą samą solą niewiele da – RT z tą kombinacją już istnieje. Dlatego ważne jest, aby każda zmiana hasła zmieniała całą parę [hash(password + salt), salt].
      Oczywiście do procesu hashowania można wprowadzić element ‘sekretny’, ale nie robi się tego przy pomocy soli. Do tego służy wrapnięcie jeszcze tego wszystkiego w HMAC, najlepiej przy pomocy klucza znajdującego się poza maszyną – np. na jakimś serwerze kluczy, na tokenie sprzętowym, na SmartCardzie.

    • Własnego szyfrowania nie ma po co wymyślać, jest tyle dobrych funkcji skrótu o dużej entropii, że do wyboru, do koloru. To samo xor i custom-base64, które też można wpleść do procedury szyfrującej po dowolnej ze stron. Tu i tu możesz zadać jakąś tajną wartość, tajny klucz. Zresztą właśnie w całym crypto chodzi o to, że algo są jawne, ale klucze tajne – dokładnie to się robi ;)

  9. Pamietam gdy pare lat temu ktos wlamal sie do infrastruktury OVH i wyciekly dane wszystkich klientow z Europy, z tego co pamietam to włamał się ktoś z wewną†rz poprzez komputer jednego z administratorów. Najwiecej ataków jest przeprowadzanych z wewnątrz (skutecznych) wiec nie zdziwilbym sie gdyby i tak bylo w tym przypadku.

    • Dlatego zasadą jest z definicji nie ufać żadnemu inputowi bez choćby prostej filtracji, nawet z adminpanelu. I nigdy webserwer z prawami roota. “Pomanipulować” ma być można tylko po terminalu i nie telnety i webshelle, tylko SSH z dobrym hasłem + dostępne tylko z VPN-a wewnętrznego.
      Zdziwilibyście się, ile urządzeń i systemów ma adminpanele tak bardzo dziurawe, że eskalacja uprawnień to dosłownie parę sekund w dom-inspectorze.

  10. Jest jakaś znacząca przewaga KeePassa nad LastPassem? Dotychczas korzystałem z tego pierwszego, ale może warto się “przesiąść”.

    • LastPass to usługa chmurowa, synchronizuje zawsze wszystko do chmury ;)

  11. “Czy zapamiętywanie haseł w przeglądarce jest bezpieczne?’

    Nie:
    https://blogs.opera.com/security/2016/08/opera-server-breach-incident/
    https://palant.de/2018/03/10/master-password-in-firefox-or-thunderbird-do-not-bother

    • Może zależy od przeglądarki, ale dobry fork popularnego Chromium szyfruje bazę haseł, czego oryginał zdaje się do dziś nie robi.

    • Robi, ale pod warunkiem, że zaznaczy się to na etapie synchronizacji przeglądarki. W przeciwnym razie niestety nie.

  12. Wlasnie ze wzgledu na takie wycieki mamy teraz RODO. Szkoda ze przy okazji kosztami oberwie wiele malych firm jak zaklady kosmetyczne ktorych jedynym zbiorem danych jest kalendarz z imionem i nazwiskiem klientki, oraz data wizyty. Heh. Takie cookkies 2.0

    • Właśnie problem w tym, że to nie usuwa ani trochę problemu, za to rozmywa odpowiedzialność.

Twój komentarz

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

RSS dla komentarzy: