Z Twittera i GitHuba wyciekły Wasze hasła. Ale nie ma powodu do paniki

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

źródło: niebezpiecznik.pl

 

 

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *