Chodzi oczywiście o to jak przechowywać hasła (i potencjalnie inne dane uwierzytelniające) w systemie tak, by były bezpieczne. Odpowiedź na to pytanie powtarzana jest jak mantra:
Hasła powinny być hashowane z użyciem kosztownego obliczeniowo algorytmu (np. scrypt, bcrypt, PBKDF2), należy do tego użyć unikalny dla każdego hasła salt i opcjonalny pepper. Szyfrowanie jest złe, bo w systemie musi być przechowywany klucz i atakujący, który uzyska dostęp do klucza będzie w stanie rozszyfrować wszystkie hasła przechowywane w bazie.
Temat dotyczy konfiguracji firewalli WEWNĄTRZ naszej sieci. Spotkałem się z nim dawno, dawno temu, jak jeszcze zajmowałem się administrowaniem, między innymi administrowaniem urządzeniami sieciowymi, ale wciąż jest żywy. Mogę powiedzieć nawet, że teraz jest bardziej aktualny niż kiedyś, bo w coraz większej ilości sieci są one podzielone na strefy, a samo filtrowanie dotyczy nie tylko ruchu przychodzącego, ale również wychodzącego.
To teraz pytanie – czy używać akcji DROP czy REJECT?
7 grudnia w Krakowie będzie miał miejsce TechCamp #6. Przez 20 minut będę mówił na nim o tym, że dane zaszyfrowane wcale nie muszą być bezpieczne. Jeśli ktoś czyta mojego bloga w miarę regularnie, powinien wiedzieć o co chodzi :)
Oryginał tego wpisu dostępny jest pod adresem TechCamp #6
Michał Zalewski w książce The Tangled Web zawarł następującą myśl:
The only reasonable approach to tag sanitization is to employ a realistic parser to translate the input document into a hierarchical in-memory document tree, and then scrub this representation for all unrecognized tags and parameters, as well as any undesirable tag/parameter/value configurations.
Niestety, często programiści myślą, że są w stanie oczyszczać HTML łatwiej. I wciąż pokutuje tutaj podejście oparte na blackliście niedopuszczalnych tagów/atrybutów/zdarzeń. Takie podejście to proszenie się o kłopoty.
Częstym problemem jest zabezpieczenie aplikacji/systemu przed klientem, który chce z tego systemu, lub jakiejś jego funkcji, korzystać zbyt często. Potrzeba takiego ograniczenia może wynikać z różnych przyczyn. Może to być na przykład zabezpieczenie przed masową enumeracją danych, ale równie dobrze powód może być bardziej trywialny – ochrona przed wyczerpaniem zasobów. Może byc na przykład tak, że “zwykłe” wyszukiwanie jest kosztowne dla serwera i złośliwy klient może wykorzystać ten fakt do wykonania ataku DoS.
Jak się przed taką sytuacją bronić? Jednym z pomysłów może być uczynienie wywołania takiej metody dużo bardziej kosztownym dla klienta, niż jej obsługa dla serwera. W jaki sposób to zrobić? Na przykład wykorzystując kryptografię.
Czasem bywa tak, że człowiekowi wpadnie do głowy jakiś pomysł. Jak wpadnie, to pół biedy. Gorzej, jeśli go zrealizuje. Mnie wczoraj wpadł pomysł by w końcu zmienić swojego wysłużonego Windows XP na Windows 8. Jak pomyślałem tak zrobiłem...
Nie, nie będę narzekał na system, bo prawdę mówiąc nawet mi się podoba. Mimo, że mój laptop jest dość leciwy, to nowy system nie działa wolniej niż XP. Jedyny problem to urządzanie się na nowo.
Oryginał tego wpisu dostępny jest pod adresem Windows 8