Preorder drugiego tomu książki sekuraka: Wprowadzenie do bezpieczeństwa IT. -15% z kodem: sekurak-book
Wyciek KSSiP – co siedzi w bazie danych osobowych prokuratorów, sędziów? Czy hasła są łatwo łamalne?
Co dopiero pisaliśmy na gorąco o niedawnym wycieku danych z KSSiP. Obecnie mamy nieco więcej informacji. Sama Szkoła pisze:
Prawdopodobne jest, że do wycieku danych osobowych doszło na skutek zaniedbania jednej (…) firm [zewnętrznych, obsługujących KSSiP – przyp. sekurak]
To rzeczywiście dość częsty przypadek, kiedy atakowany jest dostawca. Cały czas mocno enigmatyczny jest PESEL. W tabeli, która pojawiła się na jednym (i później innych) forum, nie ma PESEL-i. Sprawa więc wydawałaby się zakończona – jednak być może do naruszenia doszło jeszcze w innym obszarze, czytamy bowiem:
Brak jest danych pozwalających na jednoznaczne stwierdzenie, że przedmiotem nieuprawnionego ujawnienia były również numery PESEL.
Przy okazji warto zwrócić uwagę, że poza imieniem, nazwiskiem, emailem, telefonami czy miastem w bazie znajdują się również adresy IP (prawdopodobnie ostatniego logowania), co w połączeniu z innymi danymi osobowymi tez może stanowić dość ciekawą informację (geolokalizacja!).
Co z tym hasłami? Z jednej strony przechowywane są one z wykorzystaniem, mówiąc lekko, niezbyt bezpiecznego algorytmu MD5, z drugiej strony system Moodle dodaje długą sól (sól jest taka sama dla każdego konta, ale generowana z odpowiednio dużą długością podczas instalacji). Szybkość łamania samego MD5 jest ogromna (na średniej klasy maszynie > 11 miliardów prób na sekundę – patrz poniżej). Jednak użycie długiej soli praktycznie uniemożliwia złamanie tych haseł. To oczywiście przy założeniu, że sól nie wyciekła w trakcie ataku.
W skrócie – właściciele systemu powinno jak oka w głowie strzec pliku konfiguracyjnego Moodle z zawartą tam solą.
–ms
To chwalebne jeśli taka „globalna sól” jest trzymana oddzielnie – zawsze zmniejsza ryzyko. Ale to się, o ile wiem, nazywa tak naprawdę „pieprzem” – a rzeczywista sól, a właściwie: sole, powinny być osobne dla każdego konta i zapisane w bazie obok zahaszowanego hasła.
Dokładnie z tym pieprzem jest jak piszesz, choć developerzy Moodle sobie to nazwali solą ;)
A mogli to zrobić lepiej: oprócz pieprzu wygenerować sól dla każdego rekordu w bazie. Zwiększyłoby to bezpieczeństwo.
i użyć czegoś lepszego – np. bcrypt
A kto wygrał przetarg? Kto był wykonawcą?
a za co odpowiedzialna jest kolumna secret?
AFAIR to token generowany np. przy potwierdzeniu konta – czyli w zasadzie obecnie do niczego nieprzydatne.