Polityka bezpieczeństwa Allegro

Wgląda, że polityka bezpieczeństwa Allegro jest mocno poroniona. Z jednej strony hasła latają sobie plaintekstem (co z tego, że „tylko po serwisie”? pracowników z dostępem „trochę” jest…), z drugiej – nie przyślą (zmienionego) hasła czy URLa do zmiany hasła na podanego wieki temu przy zakładaniu konta maila bo… nie podałem nazwiska panieńskiego matki (dziwnym nie jest – nie było obowiązkowe, to po co im ono?).

Ostatnio jak rozmawialiśmy, to pracownicy Allegro byli tak dowcipni, że do resetu hasła chcieli ksero dowodu osobistego, koniecznie wysłane pocztą (żaden skan, żaden faks). Bardzo śmieszne, bardzo „bezpieczne”, bardzo ekologicznie i bardzo wygodnie. Przecież dane z DO w ogóle nie są wrażliwe. I poczta na pewno nie może ich zgubić. I na 100% trafi na uczciwą i kompetentną osobę w helpdesku. Jasne.

I jak już dostaną list z kserem dowodu, to chcą kod pocztowy i numer telefonu. Nie kojarzę, by mieli mój numer telefonu, więc w weryfikacji im to nie pomoże, ale to szczegół. Startery są po 3 zł i tyle kosztowałoby mnie mocno anonimowe przejęcie cudzego konta, jeśli znałbym hasło do maila i login Allegro, przed czym teoretycznie może zabezpieczać makulaturogenna procedura, którą proponują.

Więcej, usunięcie konta (jak patrzę, to korespondencję nt. przywrócenia konta prowadziłem rok temu, co mi po koncie, którego nie używam? tylko spam dostaję…) też wymaga zalogowania się (którego z braku hasła nie jestem w stanie wykonać).

Z jednej strony utrudnianie życia legalnym i uczciwym użytkownikom i narażanie ich danych (hasła trzymane plaintekstem, żądanie narażania na wyciek danych z DO), a z drugiej mają drugiej strony mają multikonta, choć niby weryfikacja listem itp. Z dyskusji przy wyżej linkowanym wpisie wynika, że hasła plaintekstem są po to, by wyłapywać multikonta. Niesłychanie skuteczny sposób. Nikt teraz nie będzie wiedział co zrobić, żeby mieć kilka kont na Allegro.

I po ostatniej wtopie nie jest wykluczone, że moje hasło już ktoś ma. Jakieś pomysły, z czego (poza GIODO i UOKiK) można ich w tej sytuacji ścignąć? Tak, znudziło mi się i tym razem definitywnie chcę dokończyć sprawę – ich problem, czy chcą mieć klienta, czy nie – ja nie chcę spamu, potencjalnie „wyciekniętego” hasła i braku kontroli nad swoimi danymi.

UPDATE: Teraz chcą skan dokumentu tożsamości. Nadal nie uśmiecha mi się wysyłanie tego otwartym tekstem. Oraz: szybki googiel twierdzi, że i wtedy można było skany wysyłać. Tyle w sprawie kompetencji pracowników na podstawie udzielanych informacji (Nadmienię, że dokumenty przyjmujemy jedynie drogą pocztową. Kopie nadesłane faksem czy też skany przesłane drogą mailową nie są przez nas honorowane)…

UPDATE2: Ostatecznie udało się zamknąć konto na Allegro (korzystając wyłącznie z adresu email, przy pomocy z którego (plus dodatkowe dane) nie chciano zresetować hasła. Z jednej strony odejście od procedury albo luka w niej, z drugiej przejaw zdrowego rozsądku i myślenia (w końcu!): W tej sytuacji proszę o podanie wszystkich danych, na jakie zostało założone konto, tj. imienia i nazwiska, adresu i telefonu oraz oświadczenia, iż decyduje się Pan na zamknięcie konta i usunięcie z niego danych osobowych.

Podałem dane (także telefon sprzed wielu lat, który ewentualnie mogli mieć w systemie) i zamknąłem konto (skoro i tak prawie od dwóch lat nie używałem, to po co mi ono). Czy to koniec? Skądże. Ale o tym w kolejnym wpisie (patrz trackback).

UPDATE 3 Ostatecznie przeprosiłem się z Allegro i znowu mam tam konto. Więcej o motywach powrotu w tym wpisie.

Ile cyfr potrzeba, by numer konta był unikatowy?

Temat (nie)unikatowych numerów kont pojawił się w tej dyskusji nt. tokenów (dead link, domena przejęta), a szerzej opisany jest w tym wpisie, ile cyfr potrzeba, by numer rachunku bankowego był unikatowy. Przyznam, że nie miałem zielonego pojęcia nt. algorytmu weryfikacji numeru IBAN, ale na chłopski rozum kolizje zdarzą się wszędzie. Stwierdziłem, że najlepsza metoda nauki to napisać skrypt do sprawdzania. Oczywiście w Perlu. Przy okazji wyszło mi, że Perl średnio sobie radzi z dużymi liczbami, a Python dobrze, ale dzięki temu znalazłem pięknego gotowca w postaci modułu do sprawdzania poprawności numeru IBAN.

Pierwsze, co rzuca się w oczy, to fakt, że tak naprawdę numer IBAN jest zamieniany na liczbę, a czy jest poprawny określane jest tylko na podstawie jednego testu – jeśli reszta z dzielenia tej dużej cyfry przez 97 wynosi 1, to numer jest poprawny.

Chwila zabawy programem i okazuje się, że dla 3 brakujących cyfr w dowolnym miejscu rachunku można wygenerować ok. 10 kolizji. Pewnie ma to coś wspólnego z faktem, że 97 jest liczbą pierwszą, a samo 97 mieści się w każdym tysiącu właśnie 10-11 razy, ale tutaj już by się matematyk przydał i zasady podzielności przez 97 (hasło do Google cechy podzielności przez 97 nic sensownego nie znalazło niestety).

Inna szansa, że nasze PL na początku numeru (które wraz z następującymi po nim dwiema cyframi jest przesuwane na koniec i zamieniane na liczby patrz algorytm weryfikacji numeru IBAN) jest na tyle pechowe, że powoduje taką przykrą przypadłość. Ale to łatwo sprawdzić – dzięki użyciu ogólnej biblioteki skrypcik do bruteforce’owania numerów IBAN powinien działać dla wszystkich krajów.

Póki co konkluzja jest taka, że aby numer był unikatowy, to trzeba podać wszystkie cyfry. Przy dobrym wietrze może się zdarzyć, że 1 można opuścić.

PS. Nie cierpię słowa unikalny. Dla mnie oznacza ono możliwy do uniknięcia. Zamiast niego możnaby używać słowa unikatowy. Niestety SJP traktuje je jako synonimy.

Jak często powinny występować cyfry w kodzie jednorazowym?

Wszystko zaczęło się od tego wpisu, którego głównym bohaterem jest paradoks urodzin, a który przeczytałem niedawno. Kto by pomyślał, że wybierając losowo (tylko) tysiąc liczb ze zbioru (aż) czterech milionów liczb mamy (aż!) 10% szans na to, że wybrane liczby się powtórzą? Co prawda nie liczyłem samodzielnie, ale wynik wygląda na prawidłowy. WolframAlpha co prawda wymięka dla czterech milionów, ale dla jednego miliona liczy i wychodzi ok. 39%.

Przypomniało mi się niedawne narzekanie – nie pamiętam niestety czyje – że w hasłach jednorazowych przysyłanych przez mbank SMSem takie same cyfry występują obok siebie się zbyt często, więc chyba generator pseudolosowy jest słaby czy też wręcz zepsuty. Jak mi się przypomniał ten temat, to postanowiłem policzyć prawdopodobieństwo zdarzenia, że SMS, który dostaliśmy, zawiera hasło jednorazowe z powtarzającymi się obok siebie cyframi.

Cyfr w przysyłanym haśle jednorazowym jest osiem. Prawdopodobieństwo, że cyfra kolejna jest różna od cyfry poprzedniej wynosi dokładnie 0,9. Czyli, żeby cyfry się nie powtarzały, to druga musi być inna, niż pierwsza, trzecia inna, niż druga, …, i na koniec ósma inna, niż siódma. Pierwsza cyfra nie ma się z czym powtarzać, oczywiście.

Prawdopodobieństwo zdarzenia, że wszystkie cyfry są różne wynosi zatem dla ośmiocyfrowego hasła jednorazowego 0,9^7 (pierwsza cyfra nie ma znaczenia, bo nie ma się z czym powtarzać) czyli 47,83%. Jaka jest zatem szansa, że cyfry się koło siebie powtórzą? Oczywiście prawdopodobieństwo odwrotne, czyli 1 – 0,9^7. Czyli 52,17%. Zatem, jeśli wszystkie cyfry mają takie samo prawdopodobieństwo wylosowania na wszystkich pozycjach (a tak teoretycznie być powinno), to częściej dostaniemy hasło jednorazowe, gdzie mamy powtarzające się cyfry koło siebie, niż takie, w którym się nie powtarzają. Nie ma to oczywiście nic wspólnego z pierwotnym paradoksem urodzin, ale jest ciekawe.

Nawiasem, prawdopodobieństwo, że którekolwiek cyfry w otrzymanym haśle jednorazowym się powtórzą (niekoniecznie obok siebie) wynosi aż 98% (i to już liczymy wykorzystując wzór do paradoksu urodzin).