Pisząc kod serwisu my.oodo.pl szczególną uwagę zwracam na bezpieczeństwo. I nie mówię tylko i wyłącznie o zabezpieczeniu samego serwisu przed różnymi złośliwymi atakami czy działaniami hakerów (walidacja, sanitizing, escaping wprowadzanych przez użytkownika wartości). Zgodnie z zasadą privacy by design zwracam uwagę także na to, co dzieje się z danymi osobowymi. W pewnych procesach uwzględniam od razu techniki szyfrowania danych oraz anonimizacji danych.
Szyfrowanie
Jeśli chodzi o szyfrowanie danych to szyfrowanie asymetryczne za pomocą silnych algorytmów oraz funkcji randomizujących przydaje się przy zapisywaniu w bazie haseł użytkowników. Aby hasła były bezpieczne, zaraz po ustanowieniu przez użytkownika są przekształcane za pomocą jednokierunkowych algorytmów szyfrujących w ciągi znaków. Następnie generowany jest losowy, silny ciąg znaków (tzw. sól) i dodawana do zaszyfrowanego wcześniej hasła. Następnie dodawany jest do całości kolejny dość silny ciąg znaków i całość jeszcze raz poddawana jest procesowi jednokierunkowego szyfrowania. Dane autoryzacyjne zapisywane są następnie w bazie, a w procesie autoryzacji (logowania) odtwarzany jest cały proces a przedmiotem porównania jest wyłącznie sam hash (hasz), czyli wynik szyfrowania. Jeśli szyfr zapisany w bazie zgadza się z szyfrem wygenerowanym z podanego przez użytkownika hasła - autoryzacja przebiega pomyślnie.
Jeśli do tej pory zrozumieliście logikę całego procesu to część z Was zada sobie pytanie: "dlaczego nie wystarcza samo zaszyfrowanie hasła? Dlaczego stosowana jest "sól" i "pieprz"? Otóż moi drodzy - w przypadku szyfrowania popularnymi algorytmami dość słabych i powtarzających się haseł powstają takie same hasze, które zbierane są w tzw. tęczowych tabelach/tablicach/bazach (rainbow databases, rainbow tables), w których zbierane są pary haseł i haszy. Aby ustalić hasła z wykradzionej bazy należy tylko porównać hasze w tablicach. Sól w znaczący sposób komplikuje hasło i z dużym prawdopodobieństwem zapewnia unikalny hasz, który nie znajduje się w żadnej bazie. Jeśli dodatkowo hasła zostaną popieprzone, skomplikowanie hasła wzrasta i tym samym malej prawdopodobieństwo jego złamania.
Jeśli ktoś kiedyś próbował złamać hasło atakiem wyczerpującym, to doskonale wie ile czekał na złamanie hasła składającego się z 6 znaków zawierających małe litery, duże i cyfry. Na moim, dość mocnym komputerze złamanie hasła do programu RAR zajmuje około godzinę, dwie. Dodanie do 6 znakowego hasła jednej literki z godzin robi dni. Dodanie kolejnej - miesiące. Jeszcze jedna to dekady :) Chcecie się pobawić? Zajrzyjcie TU i TU oraz TU.
Prawda że czasami warto dodać jedną literkę, cyfrę czy znak specjalny do hasła? :)
Anonimizacja
O anonimizacji danych mówimy wtedy, gdy sprowadzamy dane do takiej postaci, z której nie można odtworzyć oryginału. Ktoś z Was powie: "Po co anonimizować skoro mozna usunąć?" Ano po to aby zachować jakąś informację z danych (np. dla statystyki) lub zachować integralność bazy danych, w której składowane są dane.
Na przykład ja w swojej relacyjnej bazie danych przechowuję adresy mailowe w zindeksowanej kolumnie - oznacza to, że każdy adres mailowy musi być unikalny. Jednocześnie postanowiłem w razie anonimizacji adresu mail zachowywać pierwsze i ostatnie litery prefiksu, ilość znaków w prefiksie i całą domenę maila. W związku z tym że anonimizacja bardzo podobnych maili (składających się z tych samych początkowych i końcowych liter i tej samej ilości znaków) zaburzyłaby indeksy lub wręcz uniemożliwiłaby zapisanie danych w bazie, to do zanonimizowanych maili dodawane są dodatkowe informacje oparte na innych zindeksowanych kolumnach tego samego wiersza (to zapewnia dalszą unikalność zanonimizowanego maila). W efekcie w bazie pozostają np takie zanonimizowane maile: ba****a@gmail.comanonimizacja12, ba****a@gmail.comanonimizacja17. Dodatkową zaletą takiej anonimizacji adresów mailowych w bazie jest możliwość ponownego założenia konta czy zapisania do newslettera tego samego użytkownika, z tym sameym adresem.
Oczywiście w różnych sytuacjach anonimizacja nie będzie konieczna i jako administrator danych będziecie mogli jeszcze zatrzymać dane - np. w związku z prawnie usprawiedliwionymi celami (np. dla celów dowodowych, reklamacyjnych). W innych jednak przypadkach dane są zupełnie zbędne. Można je skasować, zniszczyć lub zanonimizować. Ja używam natychmiastowej anonimizacji w sytuacji gdy przy zakładaniu konta powstanie omyłka w adresie mailowym. Błędny adresat maila może natychmiastowo zanonimizować swojego maila w mojej bazie za pomocą linku.