Tag: strona

Opublikowane w

Skutki wycieku danych z Morele.net

Jakiś czas temu ze sklepu internetowego Morele.net wyciekły dane. W sieci zaroiło się od reakcji, dość skrajnych. Od psioczenia na słabe zabezpieczenia i „jak tak można było” i „pójdę z tym do sądu” po „nie stało się nic„.

Informacje o wycieku

Z serwisu Morele.net wyciekły maile, imiona, nazwiska, numery telefonów dla 2,2 mln kont. Oraz prawdopodobnie, dodatkowo, jak twierdzi włamywacz, a czemu zaprzeczyły Morele.net, numery PESEL oraz skany dowodów osobistych dla kilkudziesięciu tysięcy kont, a włamywacz ujawniał kolejne szczegóły na Wykopie (konto już usunięte).

Moim zdaniem prawda leży, jak to często bywa, gdzieś pośrodku. Na pewno wyciek jest ważny ze względu na skalę – 2,2 mln rekordów w skali Polski to bardzo dużo[1], w dowolnym aspekcie – czy to do wysyłki spamu, czy do ataków phishingowych przy pomocy SMSów, czy wreszcie jako baza haseł, zarówno do próby bezpośredniego wykorzystania ich w innych serwisach, jak i do analizy i budowy słowników w kolejnych atakach.

W informacjach o wycieku z Morele.net poruszony był aspekt niezłego hashowania haseł. Niestety te niezłe hashe w praktyce niewiele wnoszą – być może nie uda się złamać, w sensownym czasie i sensownym kosztem, najtrudniejszych haseł, ale najsłabsze ok. 20% można złamać na CPU na pojedynczym komputerze w ciągu pojedynczych godzin.

Jeśli informacja o wycieku skanów dowodów jest prawdziwa, to jest to dla ofiar spory problem – możliwości do nadużcia spore, PESEL w zasadzie niezmienialny, a wymiana dowodu kłopotliwa. Przypuszczam, że chodzi tu tylko o kupujących na raty.

Hasła

Pozostałe 2,2 mln niespecjalnie ma powody do zmartwień, jeśli tylko nie stosuje schematycznych haseł oraz ma osobne hasła do różnych serwisów. W tym miejscu gorąco polecam programy do przechowywania haseł w stylu Keepass.

Jeśli hasła są różne w różnych serwisach to nawet ich siła nie ma specjalnego znaczenia, o ile w serwisie są tylko dane z bazy, nie można zrobić zakupu itp. OK, atakujący dostanie się do konta w sklepie internetowym. Co zobaczy, czego jeszcze nie wie? Historię zakupów? Ironizuję, ale zakładam, że nie jest w stanie robić zamówień itp. bez dodatkowego potwierdzenia. Mógł za to usunąć konto, jednym kliknięciem, bez potwierdzania. Cóż, to strata głównie dla sklepu – jeśli ktoś potrzebuje to założy nowe konto…

Maile

Jeśli chodzi o maile, to jest spora szansa, że już wcześniej trafiły do baz spamerów i marketerów. Chyba, że ktoś stosuje oddzielne aliasy do serwisów, ale wtedy zupełnie nie ma problemu – wystarczy usunąć alias. Podobnie z numerami telefonów. A jeśli ktoś chce mieć święty spokój, to przypominam, że usługi GSM tanieją i numer telefonu płatny w formie prepaid można mieć już za 5 zł rocznie i używać go w różnych mniej istotnych miejscach. Oczywiście można to zrobić w nowocześniejszy sposób.

Konta w sklepach internetowych

Tu dochodzimy do sedna: czy do zakupu w każdym sklepie internetowym faktycznie potrzebne jest zakładanie konta? Niektóre sklepy wymuszają założenie konta, ale staram się takich unikać, a z paru zakupów zdarzyło mi się zrezygnować z tego powodu. Jeśli już zakładamy konto, to dobrze by było, żeby wymagane było podawanie jak najmniejszej ilości danych. Zupełnie dobrze by było, gdyby serwisy pozwalały na ustawienie po jakim czasie nieaktywności usunąć konto lub chociaż cyklicznie przypominać mailem o takiej możliwości.

[1] Kolejny duży polski wyciek, który kojarzę to ~700 tys. z Filmweb. Oczywiście polskie konta występują też na wyciekach światowych i będą to porównywalne ilości.

UPDATE: Wpis nieco przeleżał jako szkic i został ostatecznie opublikowany w formie nieco pociętej. Mimo tematu, który pozostał z wersji oryginalnej, celowo pominąłem m. in. spekulacje nt. skutków dla Morele.net i chciałbym, aby tak pozostało, również w komentarzach.

UPDATE2: Jak donosi Zaufana Trzecia Strona, baza sklepu Morele.net została ujawniona przez włamywaczy. Jakieś pięć miesięcy po ataku.

Opublikowane w

Szybkość polskich stron internetowych cz. 2

Opisywany w poprzednim wpisie nt. badania szybkości polskich stron internetowych system trochę okrzepł, skończył się miesiąc, więc pora na konkrety. Co prawda listę badanych serwisów było widać na zrzucie ekranu, ale nie było dostępu do danych , więc teraz to naprawiam.

Zdecydowałem, że nie będę się bawił w wyciąganie średnich miesięcznych itp.  Jeśli ktoś jest zaintersowany, to w historii są linki do danych źródłowych (CSV), można sobie wyciągnąć samodzielnie. O ile ktoś będzie potrzebował, bo to, co domyślnie daje GTmetrix, z ładną wizualizacją, jest IMO w zupełności wystarczające.

Tak więc badanie wywoływane jest dla 10 wybranych serwisów (najpopularniejsze polskie oraz ecommerce, przy czym znaczenie miała domena) co 12h. Wykonywane z Londynu, przy pomocy Chrome, bez AdBlocka i na nielimitowanym paśmie.

Oto serwisy, po kliknięciu linka dostęp do wszelkich zebranych danych:

Jest jeszcze pomysł na uruchomienie testów za pośrednictwem innego serwisu. Jednak na razie pozostaje to w sferze pomysłów, póki co bez planów na implementację.

UPDATE: Pomysł na sprawdzanie szybkości polskich stron internetowych wyglądał fajnie, ale tylko przez miesiąc. Po pierwsze, okazało się, że dostępne są dane tylko z miesiąca, mimo obiecujących wartości „1y” i „all” w historii. Po drugie, skrypt wymaga poprawki – przez parę dni dane się nie zbierały, potem samoistnie zaczęły. Pewnie do poprawy obsługa wyjątków plus dodanie wysłania powiadomienia. Przy czym założenie, że mógłbym coś zrobić i że by mi się chciało jest mocno optymistyczne. Po trzecie i najważniejsze, zmieniły się linki do raportów. Powyższe już nie działają, co oznacza, że nawet wersja miesięczna jest średnio używalna dla kogokolwiek poza mną. Pomyślę jak to wszystko rozwiązać, pewnie skończy się na powrocie do oryginalnego pomysłu i zbierania danych samodzielnie.

Opublikowane w

Pomiar szybkości polskich stron internetowych

Podczas pewnej dyskusji nt. kondycji stron internetowych powołane zostało jako argument badanie szybkości stron internetowych robione przez firmę Hostersi. Jest to ciekawe badanie, prowadzone od lat ale… ma wady.

Pomiarów niby jest dużo, ale są one przeprowadzane przy pomocy autorskiego narzędzia uruchamianego ad hoc, przez tydzień. Samo badanie publikowane raz na rok. Wszystko to powoduje, że wyniki trudno jest weryfikować samodzielnie. Dodatkowo jakaś zmiana na stronie obecna w danym tygodniu, czy chwilowe problemy wydajnościowe serwisu mogą zaburzać wyniki dla całego roku. Co widać nawet w raporcie po niektórych dziwnych danych.

Dla jasności – szanuję wykonaną pracę. Jednak gdyby to zależało ode mnie, wolałbym mieć dane zbierane z dłuższego okresu, choć z mniejszą rozdzielczością. Czyli patrzeć na trendy powiedzmy kwartalne, kosztem podatności na błąd pojedynczego pomiaru. Ale w dłuższym okresie i tak się to uśredni.

I tak narodził się pomysł, żeby zbierać i publikować w miarę na bieżąco dane dotyczące szybkości działania polskich stron internetowych samodzielnie, hobbystycznie, w sposób umożliwiający każdemu chętnemu samodzielną weryfikację wyników pomiarów.

Stawianie własnej infrastruktury oczywiście odpadło w przedbiegach. Zbyt zasobochłonne, zarówno jeśli chodzi o koszt, jak i o samą czasochłonność utrzymania. Poza tym, odpadnie możliwość peer review. Jednak serwis GTmetrix daje ciekawe możliwości badania szybkości ładowania stron i daje API. Postanowiłem z niego skorzystać, co sprowadza pracę do napisania prostych skryptów w Pythonie. Dodatkowo pozwala dzielić się zebranymi danymi przy pomocy udostępniania unikatowych URLi.

Niestety, w wersji darmowej można robić tylko 20 zapytań po API dziennie. To wymusiło ograniczenie się do jednej lokalizacji (Londyn, jako najbliższy Polsce), jednej przeglądarki (Chrome bez AdBlocka). Musiałem też zmniejszyć liczbę badanych serwisów do 10 (wybrane na podstawie raportu Hostersi z najpopularniejszych i ecommerce) i wykonywania dla każdego 2 testów dziennie. Wybrałem okolice godziny 8 rano oraz 20. Z doświadczenia o 8 jest już jakiś – choć niewielki – ruch w sieci, a 20 to szczyt. Wyniki planuję publikować co miesiąc, jako średnie wartości z danego miesiąca.

Badane strony w GTmetrix

Póki co, uruchomiłem skrypt, który przy pomocy crona robi „taktowanie”, czyli zleca uruchomienie testów. Dane zbierają się od paru dni. Pomyślę jeszcze, czy zamieszczać jakieś statystyki co miesiąc, czy po prostu ograniczyć się do zbierania. Raczej stanie na tym drugim… Stay tuned!