Preorder drugiego tomu książki sekuraka: Wprowadzenie do bezpieczeństwa IT. -15% z kodem: sekurak-book
(Nie)bezpieczeństwo danych w firmie – czyli po co mi ISO 27000 – część 2
Pierwsza część artykułu dotyczyła zakresu planowania bezpieczeństwa informacji ze szczególnym uwzględnieniem roli najwyższego kierownictwa w tym procesie oraz obowiązków i uprawnień pracowników. W tej części zagłębimy się w tematykę aktywów, kontrolowania dostępu do nich i ich zabezpieczania.
Zarządzanie aktywami
Aktywa informacyjne to innymi słowy wszelkie urządzenia, oprogramowanie, informacje czy elementy infrastruktury, które mają znaczenie dla danej organizacji i wpływ na bezpieczeństwo informacji. Dlatego też muszą być one odpowiednio zabezpieczane i monitorowane. Dobrą praktyką jest utworzenie zestawienia aktywów, zawierającego dane identyfikujące je, tzn. czym są, kto jest ich opiekunem, gdzie się znajdują i jakie mają znaczenie dla organizacji (w tym kontekście można posłużyć się analizą ryzyka opisaną w ISO/IEC 27005). Dla określonych aktywów powinny także istnieć procedury ich zabezpieczenia, jak np. sposób i częstotliwość backupowania. Stan aktywów powinien być cały czas monitorowany, aby zapobiegać możliwości braku dostępności danych – jeśli np. dyski określonej serii często się psują, to należy wymienić je na inne, aby dane na nich zawarte były bezpieczne i zawsze dostępne. Powinno się też przechowywać historię aktywów w celu późniejszej analizy w przypadku wystąpienia np. wycieku danych lub określenia przyczyn awarii jakiegoś urządzenia.
Każda organizacja działa oczywiście w innym środowisku, więc każda będzie miała inne wytyczne dotyczące postępowania z aktywami przez pracowników, niemniej powinni być oni świadomi jakie są zasady, aby nie narażać krytycznych informacji na przypadkowe ujawnienie. Tak jak już to było zaznaczone w pierwszej części serii, pracownicy muszą wiedzieć jak chronić dane i urządzenia w środowisku, w którym pracują (np. urzędnik nie może zostawiać dokumentów lub urządzeń bez opieki, kiedy wychodzi z pokoju, w którym zostaje jego petent).
Tak samo jak w przypadku ról, tak też w przypadku aktywów zwalniany pracownik musi się rozliczyć z wykorzystywanego dotychczas sprzętu, oprogramowania, dokumentów itp. Jeśli do pracy używał prywatnego sprzętu, należy się upewnić, że wszystkie dane zostały przeniesione na urządzenia będące pod kontrolą firmy i usunięte z jego urządzenia. Warto w takich przypadkach wykonać protokół z przekazania aktywów przez pracownika.
Klasyfikacja informacji
Aby ułatwić nieco określanie jakie aktywa są bardziej a jakie mniej krytyczne dla danej organizacji, sugeruje się skorzystanie z klasyfikacji aktywów, zawierającej kilka poziomów ważności – od najniższego do najwyższego. Jednym z bardziej rozpoznawalnych przykładów klasyfikacji informacji jest klasyfikacja zgodna z Ustawą o ochronie informacji niejawnych – od „zastrzeżone” do „ściśle tajne”, ponieważ ze względu na precyzujące ją zapisy ustawy, rozumienie tych poziomów jest wszędzie takie samo. Oczywiście każda organizacja może stworzyć taką klasyfikację, jaka będzie dla niej najbardziej zrozumiała.
Klasyfikacja poufności czy krytyczności aktywów nie jest nadawana raz na zawsze. W przypadku kiedy firma opracowuje nową technologię lub korzysta z elementów, których ujawnienie przyczyniłoby się do zmniejszenia jej konkurencyjności na rynku, dane technologiczne mają wysoką klauzulę. Kiedy jednak informacja o produkcie zostanie upubliczniona, klasyfikacja tych danych może zostać obniżona, aby sztucznie nie wprowadzać ograniczeń w pracy.
Gdy nadamy jakimś aktywom klasyfikację, musi być ona łatwo rozpoznawalna i zauważalna. W przypadku aktywów fizycznych jest to o tyle łatwiejsze, że wystarczy ich oklejenie w widocznym miejscu. W przypadku informacji oznaczanie ich tak, aby było to jasne dla wszystkich osób je przetwarzających, jest już trudniejsze. Można w tym momencie zastosować metadane, które dodatkowo ułatwią nam automatyczne rozpoznawanie klasyfikacji przez systemy informatyczne. Jeśli klauzula danej informacji jest niska, można nawet pominąć oznaczanie, aby uniknąć niepotrzebnej, dodatkowej pracy. Dla aktywów o wysokiej klauzuli należy zapewnić dodatkowe środki bezpieczeństwa, takie jak częstsze backupy (wraz z upewnieniem się, że faktycznie da się z nich odzyskać dane), silniejszą kontrolę dostępu itp. Jest to podyktowane tym, że ze względu na swoją wagę dla organizacji, aktywa te mogą tym bardziej stać się obiektem ataku włamywaczy (fizycznych lub hakerów), nie tylko chcących zaszkodzić danej organizacji, niszcząc kluczowe aktywa lub pozyskać jej „sekretną” wiedzę, ale także tych, którzy widząc coś o większym znaczeniu, tym bardziej będą chcieli to ukraść.
Zarządzanie nośnikami danych
Jeśli już jesteśmy przy dodatkowych zabezpieczeniach dla aktywów fizycznych, to należy wspomnieć także o procedurach postępowania z wymiennymi nośnikami danych. Jako urządzenia o większej podatności na kradzież lub zgubienie czy zniszczenie, a także ze względu na częste przypadki przenoszenia na nich złośliwego oprogramowania, powinno się opracować sposoby postępowania z nimi. Niektóre organizacje wprowadzają nawet w politykach bezpieczeństwa kont użytkowników (GPO) ustawienia uniemożliwiające podłączanie nośników danych na USB. Dyski z backupami trzeba np. przechowywać w odpowiednich warunkach klimatycznych i zapewniać im bezpieczne opakowania na czas transportu. W przypadku zużycia się lub zepsucia takiego nośnika, powinna istnieć odpowiednia procedura mówiąca kto i w jaki sposób musi zniszczyć dane urządzenie, aby niemożliwe było odzyskanie z niego danych. Procedura taka może np. przewidywać użycie oprogramowania czyszczącego dysk poprzez nadpisanie go danymi losowymi i późniejsze komisyjne zdemagnetyzowanie i zniszczenie fizyczne dysku z wykonaniem dokumentacji fotograficznej przebiegu czynności. Pamiętajmy, że tzw. dumpster diving, czyli nurkowanie w śmietnikach firm niepozbywających się w odpowiedni sposób swoich wymiennych nośników danych, jest jednym ze sposobów rekonesansu przed atakiem na daną organizację.
W przypadku używania nośników wymiennych do przenoszenia danych (backupy, obszerna dokumentacja itp.) do innej lokalizacji niż nasza firma, co jest jednym ze sposobów minimalizowania ryzyka związanego ze zniszczeniem danych z powodu pożaru lub powodzi, należy zaprojektować ten proces tak, aby zapewnić im jak największe bezpieczeństwo. Oprócz fizycznego zabezpieczenia nośników warto również zabezpieczyć same dane odpowiednimi metodami kryptograficznymi. Osoby transportujące urządzenia powinny być sprawdzone, a ich dane zapisane, w celu zapobieżenia sytuacji kiedy nie wiemy kto i kiedy pobrał nośniki. Jeśli nie jesteśmy pewni czy osoba, której chcemy przekazać krytyczne dane, na pewno może je otrzymać (przykładowo pojawia się osoba podająca się za nowego kuriera „bo poprzedni zachorował/zwolnił się” lub brakuje dokumentów przewozowych), powinna zapalić nam się kontrolka w głowie i powinniśmy zweryfikować możliwość przekazania przesyłki danej osobie w co najmniej jeszcze jednym źródle. Może nas to uratować przed socjologicznym atakiem mającym na celu wykradzenie naszych kluczowych aktywów.
Kontrola dostępu
Aby zapewnić bezpieczeństwo informacji, a jednocześnie umożliwić pracownikom (w miarę) bezproblemowe wykonywanie obowiązków, konieczne jest wprowadzenie mechanizmów kontroli dostępu. Najbardziej ogólną zasadą przydzielania dostępu do danych jest zasada, która może wydać się znajoma dla osób konfigurujących firewalle – na początek dajemy regułę „deny all”, a następnie dajemy dostęp tylko i wyłącznie do tego, co konieczne. Oczywiście do przyznawania dostępu uprawniona może być tylko określona grupa osób (administratorzy i/lub właściciele aktywów), która będzie kontrolować kto i do czego ma lub może mieć dostęp, aby nie doprowadzić do konfliktu interesów. Drugą ważną zasadą jest monitorowanie aktywności użytkowników w celach późniejszego audytowania. W przypadku wykrycia podejrzanych działań musi istnieć możliwość jak najszybszej analizy ich źródła, aby zapobiec przypadkowym lub celowym atakom. Kontrola dostępu oczywiście nie odnosi się tylko do dostępu do informacji, ale także fizycznego dostępu do miejsc i urządzeń. Jak każdą inną politykę bezpieczeństwa informacji, także zasady kontroli dostępu należy często przeglądać i aktualizować.
Jednym z aspektów kontroli dostępu jest odpowiednie zabezpieczenie sieci wewnątrzfirmowej przed nieuprawnionym dostępem, zarówno przez gości odwiedzających daną firmę, jak i przez pracowników, jeśli sieć jest podzielona na niezależne części. Dostęp powinien być oparty na informacjach umożliwiających odróżnienie sprzętu znanego od nieznanego. Do tego celu można wykorzystać prostą metodę rozpoznawania sprzętu po adresach MAC lub też dające o wiele większy poziom bezpieczeństwa uwierzytelnianie przy pomocy certyfikatów X.509. To tyczy się zarówno sieci przewodowej, jak i bezprzewodowej. Aby jednak ułatwić gościom pracę podczas pobytu w danej firmie, możliwe jest zapewnienie im tylko dostępu do internetu, bez możliwości dostępu do sieci wewnątrzfirmowej. Należy jednak pamiętać, że przydzielony dodatkowo dostęp, czy to gościom, czy pracownikom, powinien być odebrany w momencie, kiedy już nie jest wymagany. Jeśli dana firma uzna to za stosowne, może także ograniczyć dostęp ze swojej sieci do określonych stron w internecie (np. do portali społecznościowych).
Tworzenie zasad dostępu przez użytkowników
Większość zasad postępowania w przypadku zatrudniania nowej osoby opisanych jest w rozdziale dotyczącym zasobów ludzkich, jednak w zakresie kontroli dostępu wskazane jest opracowanie procedur tworzenia kont i nadawania uprawnień, aby zminimalizować ryzyko popełnienia błędu przy wykonywaniu takiej czynności. Ta sama procedura powinna uwzględniać zmianę stanowiska pracy przez pracownika oraz zakończenie współpracy. Jeśli okaże się, że dostęp nie jest już konieczny, to w zależności od sytuacji należy usunąć uprawnienia danego konta lub nawet usunąć całe konto z systemu. Działanie takie powinno być wykonywane tak szybko jak to tylko możliwe, szczególnie kiedy istnieje podejrzenie, że dalszy dostęp będzie się wiązał z ryzykiem utraty lub wykradzenia danych.
Może zdarzyć się sytuacja, że jedno konto nie jest przypisane na stałe do jednej osoby, ale do jednego stanowiska, na którym pracuje kilka osób na różnych zmianach. W takim wypadku należy wdrożyć logowanie dwóch rodzajów zdarzeń – aktywności danego konta w systemie oraz czasu pracy danego pracownika na stanowisku wykorzystującym to konto. Jest to konieczne, aby umożliwić późniejszą jednoznaczną weryfikację kto jest odpowiedzialny za dane działanie w systemie.
Tak samo jak ważne jest określenie ról dla osób w organizacji, tak samo wskazane jest określenie ról użytkowników systemów informatycznych i niemodyfikowanie ich (chyba, że wystąpi naprawdę taka potrzeba). Stworzenie zbyt wielu ról prowadzić może do chaosu w przydzielaniu praw, dlatego schemat nazewnictwa i zakresu uprawnień w ramach ról w systemie należy uprzednio gruntownie przemyśleć i przeanalizować.
Oprócz kont „zwykłych” użytkowników w systemie muszą istnieć także konta administracyjne, o dużo wyższych prawach. Biorąc pod uwagę fakt, że działanie na takim koncie niesie ze sobą dużo wyższe ryzyko doprowadzenia do destabilizacji lub awarii systemu, powinno ono się odbywać z zachowaniem najwyższych środków ostrożności. Nie zaleca się także pracy na koncie administracyjnym na co dzień, a tylko w przypadku konieczności wykonania zadań wymagających podwyższenia uprawnień (to samo tyczy się też działania w systemach operacyjnych). Chodzi o to, aby uniknąć sytuacji, gdzie wylanie kawy na klawiaturę spowoduje przypadkowe usunięcie np. całej bazy danych z systemu (w najczarniejszym scenariuszu). Dodatkowo praca na takim koncie pociąga za sobą ryzyko włamania się do systemu poprzez wykorzystanie chwili nieuwagi osoby, która cały dzień pracuje na koncie administratora, a akurat chwilowo opuściła stanowisko pracy nie blokując komputera.
Uprzywilejowany dostęp do danych
W przypadku przyznawania pracownikom praw dostępu na poziomie administratora informacja taka powinna być gdzieś zapisana, aby możliwa była weryfikacja kto i kiedy miał taki poziom uprawnień. Jeśli dany pracownik nie potrzebuje już konta administratora, taki poziom dostępu powinien być jak najszybciej zdjęty z jego konta. Każdy, kto ma dostęp do kont uprzywilejowanych w systemie, powinien zostać do tego przeszkolony oraz poinformowany o możliwych konsekwencjach i karach związanych z wykorzystywaniem uprawnień do własnych celów i korzystaniem z nich niezgodnie z otrzymanymi poleceniami.
W celu upewnienia się, że kiedyś przyznane uprawnienia nadal są aktualne, konieczny jest cykliczny przegląd nadanych użytkownikom praw i weryfikacja, czy na pewno jeszcze potrzebują takiego poziomu dostępu. Im ważniejsze dane, do których użytkownicy mają dostęp, tym częstotliwość takiej weryfikacji powinna być większa. Jeśli podczas takiego sprawdzenia wykryty zostanie nietypowy poziom dostępu jakiegoś użytkownika, sytuacja powinna zostać wyjaśniona i zmieniona.
Także dostęp do funkcji systemu, które mogą mieć wpływ na bezpieczeństwo, powinien być kontrolowany. Jeśli każdy użytkownik będzie miał możliwość zmiany ustawień firewalla lub wyłączenia oprogramowania antywirusowego, może to skutkować obniżeniem poziomu bezpieczeństwa systemu i danych. Dostęp do tego typu funkcji powinien być ograniczony do niezbędnego minimum, przyznawany tylko po uzasadnieniu takiej potrzeby i tylko na określony czas. Informacja o przyznaniu dodatkowego dostępu powinna być oczywiście zapisana w celu późniejszych ewentualnych weryfikacji.
Podaj hasło
Osobnym tematem w zakresie kontroli dostępu są hasła umożliwiające zalogowanie się do systemu informatycznego lub urządzenia, a także, w przypadku elementów infrastruktury, wejście do określonych pomieszczeń. Generowanie i przekazywanie takich haseł pracownikom powinno być elementem procedury zapewniającej, że będzie się to odbywało w sposób bezpieczny i nie dający możliwości ich ujawnienia, a hasła takie powinny być przez użytkowników zmieniane przy pierwszym logowaniu.
Także późniejsze przechowywanie haseł, PINów, kart dostępu i innych środków dostępu powinno mieć zapewniony odpowiedni poziom bezpieczeństwa, a pracownicy powinni zostać przeszkoleni w zakresie ochrony informacji dostępowych, zarówno otrzymanych, jak i generowanych przez siebie – niezapisywanie haseł otwartym tekstem w plikach, niewieszanie na tablicy ani na monitorze, niewykrzykiwanie swojego lub czyjegoś hasła przez całe pomieszczenie lub korytarz, niezostawianie kart dostępu bez opieki, niedzielenie się swoimi kodami dostępu (czasami nawet z najbliższymi, jeśli wymaga tego poziom ochrony) itd., itp. W przypadku zgubienia danych dostępowych lub podejrzenia ich wycieku, sytuacja taka musi być jak najszybciej zgłoszona, a dane zmienione. Warto także wymusić konieczność zmian haseł co jakiś czas (dla systemów operacyjnych można to określić dokładnie w politykach bezpieczeństwa GPO), aby zminimalizować ryzyko użycia przechwyconego hasła.
Podczas tworzenia haseł powinny być uwzględnione zasady odpowiedniej ich złożoności, aby zminimalizować możliwość dostępu przy użyciu ataku słownikowego lub opartego na znajomości danej osoby (np. jej imienia, daty urodzenia itp.). Tworząc nowe hasło, należy także wziąć pod uwagę fakt, że stosowanie tego samego hasła w systemach firmowych i prywatnych nie jest dobrym pomysłem. Dużo skomplikowanych haseł może stanowić pewien problem przy zapamiętywaniu ich, można więc skorzystać z oprogramowania do przechowywania haseł (ale tylko takiego, które jest dopuszczone do użytku w danej organizacji) lub stosować logowanie z użyciem jednego źródła autentykacji, np. w oparciu o LDAP.
Zarządzanie prawami dostępu
Nie każdy użytkownik systemu informatycznego powinien mieć dostęp do całego zestawu informacji w nim zawartych – to jasne. Ale także warto przemyśleć temat dostępu do funkcji systemu, czy na pewno wszyscy wymagają dostępu np. do wprowadzania nowych danych i ich edycji czy też do generowania raportów. Nawet w obrębie jednej funkcji, jeśli jest to możliwe, należy przeanalizować konieczność dostępu do pełnych danych – zakresy raportów mogą być zależne od roli, jaką użytkownik ma w systemie (np. nie wszyscy muszą widzieć dane finansowe w raportach).
Mówiąc o sposobie uzyskania dostępu do systemu, najczęściej mamy na myśli login i hasło lub kod PIN, jednak dostęp może być oparty na dowolnym mechanizmie weryfikacji użytkownika – od kart dostępu, poprzez tokeny do kodów jednorazowych, aż do czytników danych biometrycznych: linii papilarnych, siatkówki oka czy rozpoznawania twarzy. Ważne, aby zabezpieczenia były na tyle skuteczne, aby chronić system na dobrym poziomie (dobrym, gdyż moim skromnym zdaniem nie ma systemu, którego nie można złamać, więc dążenie do ideału trzeba na jakimś poziomie zatrzymać).
Bezpieczne logowanie
Jeśli stosujemy login i hasło, ich przesyłanie w sieci powinno być wykonywane kanałem szyfrowanym (np. HTTPS, SFTP), aby uniemożliwić przechwycenie tych danych w przypadku sniffingu sieci. Sesje użytkownika powinny być ograniczone czasowo, aby ewentualny haker, któremu uda się podszyć pod nas w przypadku np. ataku poprzez przechwycone ciasteczka, miał ograniczony czas na swoje działania. W przypadku próby złamania hasła metodą brute force, system powinien po kilku błędnych hasłach blokować konto użytkownika. Hasła nie powinny być także wyświetlane otwartym tekstem podczas ich wpisywania, aby uniknąć ich przechwycenia przez osoby spoglądające nam przez ramię (tzw. atak „shoulder surfing”), a po zalogowaniu się użytkownika w systemie powinien zostać wyświetlony czas ostatniego poprawnego oraz niepoprawnego logowania – pozwala to zweryfikować czy ktoś nie użył naszych danych dostępowych lub nie próbował złamać zabezpieczeń naszego konta. Dodatkowo może być wyświetlany także np. adres iP, z którego nastąpiła ostatnia nieudana próba uwierzytelnienia.
Dostęp do kodów źródłowych programów (a także elementów z nimi związanych, jak specyfikacje czy zasady testów) powinien być ograniczony i podlegać procedurom zapewniającym, że osoby, które nie muszą mieć do nich dostępu, nie uzyskają go. Sugeruje się przechowywanie kodów źródłowych w bezpiecznym środowisku, aby zachować jego poufność i nie dopuścić do wprowadzenia niepożądanych funkcjonalności, a także zachować odpowiednią ochronę wartości intelektualnych w nich zawartych. Środowisko takie może być zabezpieczone fizycznie poprzez skoncentrowanie repozytorium w jednym miejscu (co ułatwia jego nadzorowanie) i regularnie wykonywane backupy, a także poprzez zapewnienie dostępu do środowiska deweloperskiego tylko poprzez kanały VPN i monitorowanie możliwych wycieków kodów źródłowych.
Kryptografia
Zawarte tutaj wskazówki przedstawiają sposoby zapewnienia ochrony informacji poprzez wprowadzenie polityk określających zasady używania zabezpieczeń kryptograficznych, aby zagwarantować poufność i integralność danych podczas ich przesyłania i przenoszenia. Dla różnych poziomów poufności informacji konieczne jest zdefiniowanie w jaki sposób będą szyfrowane – co raczej oczywiste, im informacja jest ważniejsza dla organizacji lub większe szkody może przynieść jej wyciek, tym lepszy poziom zabezpieczeń powinien być stosowany. Jeśli np. stosujemy dyski lub pendrive’y, które zawierają wrażliwe dane, a są przenoszone poza teren firmy, musimy je odpowiednio zabezpieczyć przed nieuprawnionym dostępem. To samo tyczy się dostępu do firmowych danych wystawionych na serwerze plików lub na stronie dostępnej przez internet.
Należy również zapewnić zabezpieczenie kanału dostępu do danych firmowych spoza wewnętrznej sieci (poprzez stosowanie np. VPN). Jeśli do przesyłania ważnych informacji używamy e-maili, to musimy pamiętać o tym, żeby dodatkowo szyfrować ich treść, gdyż bez tego dane są narażone na łatwe odczytanie przez nieuprawnione osoby. To samo tyczy się wrażliwych informacji przesyłanych przez sklep internetowy (np. dane karty kredytowej kupującego) – tutaj także zabezpieczenie komunikacji jest priorytetem. Co prawda szyfrowanie informacji pomaga w zabezpieczeniu jej przed nieautoryzowanym dostępem, ale także niesie za sobą pewne niebezpieczeństwa. Jeśli przykładowo dane zaszyfrowane przesyłane do firmy będą zawierały złośliwe oprogramowanie, to może ono zostać wykryte dopiero po ich odszyfrowaniu, a nie podczas ich przesyłania.
Istotną kwestią jest zapewnienie odpowiedniego postępowania z utraconymi hasłami. W przypadku wystąpienia takiego zdarzenia nie ma bowiem czasu na zastanawianie się co i w jakim zakresie należy zrobić, aby uniknąć utraty informacji – wystarczy wykonanie serii czynności przewidywanych przez wcześniej przygotowaną procedurę, której opracowanie musi być poprzedzone dogłębną analizą wszelkich możliwych scenariuszy zdarzeń.
Postępowanie z kluczami kryptograficznymi
Wskazane jest także, by określić sposób postępowania z kluczami – zasady ich generacji (włącznie z używanymi algorytmami i ich parametrami), zabezpieczenia (zarówno pod kątem samych kluczy, jak i fizycznie sprzętu używanego do ich generowania), dystrybucji, aktualizacji i usuwania. Jeśli generowane są również klucze tymczasowe (np. dla tymczasowego dostępu przez VPN), należy opracować procedury postępowania przy zakończeniu ich cyklu życia i blokowania połączeń w oparciu o klucze, które już są nieaktualne.
Podsumowanie
Omówione zabezpieczenia aktywów pokazują nam jakie kwestie informatyczne powinniśmy brać pod uwagę organizując infrastrukturę naszej organizacji, aby zapewnić bezpieczeństwo informacji w niej przetwarzanych. Pamiętajmy jednak, że każda organizacja jest inna i opisane sposoby postępowania trzeba dostosować do jej specyfiki. W kolejnej części skupimy się na fizycznym środowisku, bezpiecznej komunikacji oraz odpowiednim podejściu do bezpiecznej eksploatacji systemów w firmie.
– KW
Nikt już po 1 części nie przeczytał czy brak komentarzy wynika z czegoś innego?
Na sekuraku przy większych tekstach zazwyczaj jest mało komentarzy :/ Albo takie które wskazują drobne rzeczy do korekty (za co zawsze jesteśmy wdzięczni). Patrz np.: https://sekurak.pl/czym-jest-cors-cross-origin-resource-sharing-i-jak-wplywa-na-bezpieczenstwo/
Ja chciałem! Ja chciałem się udzielić, ale przy tej części nie bardzo jest przy czym.
No bo jak się przyczepić do używania hashów przy zapisywaniu haseł w bazie? ;p
Ja przeczytałem :-)
Ja też przeczytałem