BIP, BIP, BIP
Jestem, nic mi nie jest. Pewnie za jakiś czas napiszę coś konkretnego.
Oryginał tego wpisu dostępny jest pod adresem BIP, BIP, BIP
Autor: Paweł Goleń
Jestem, nic mi nie jest. Pewnie za jakiś czas napiszę coś konkretnego.
Oryginał tego wpisu dostępny jest pod adresem BIP, BIP, BIP
Autor: Paweł Goleń
Załóżmy, że mamy przechować jakiś sekret. Nie do końca chodzi nam o to, by był on przechowywany w sposób nieodwracalny, natomiast zdecydowanie chcemy mieć możliwość sprawdzenia, czy określona osoba ten sekret zna.
Tak, dokładnie o to chodzi również przy przechowywaniu haseł. Tu absolutnym standardem jest przechowywanie sekretów (haseł) w formie skrótu (hasha), który powinien być nie tylko nieodwracalny, ale również kosztowny do wyliczenia. Wszystko po to, by atak brute force był jak najbardziej kosztowny (obliczeniowo). Są jednak takie przypadki, w których przestrzeń możliwych wartości sekretu jest na tyle niewielka, że podejście oparte na wykorzystaniu hasha po prostu się nie sprawdza.
W takich przypadkach lepszym podejściem jest zaszyfrowanie sekretu i przechowywanie go w takiej postaci. Oczywiście szyfrowanie musi być wykonane z głową, bo inaczej skutki są takie: Anatomy of a password disaster – Adobe's giant-sized cryptographic blunder.
Jeśli szyfrowanie zostanie zrealizowane poprawnie, to atak na hasła sprowadzi się do ataku na wykorzystany szyfr. W praktyce oznacza to konieczność odgadnięcia klucza, który ma co najmniej 128 bitów. Powodzenia.
Ale jednocześnie właśnie tu jest problem – system by działać, musi mieć dostęp do tego klucza. Z pewnym prawdopodobieństwem należy więc założyć, że również atakujący będzie miał do niego dostęp (choć w przypadku wspomnianej już wpadki Adobe – klucza najwyraźniej nie udało się zdobyć).
Jaki stąd morał? Warto zastanowić się co chcemy chronić i jaka jest możliwa przestrzeń wartości tego sekretu. W pewnych sytuacjach bardziej bezpiecznym rozwiązaniem będzie wybranie szyfrowania i próba utrudnienia dostępu do klucza.
P.S. W zasadzie dokładnie to samo można osiągnąć przy pomocy tajnego pepper (uzupełniając jawny salt). Oczywiście tutaj należy z kolei zadbać o to, by pepper nie był łatwo dostępny dla atakującego.
P.S2. A przypomniało mi się to w związku z tym: Can hackers decrypt Target's PIN data? Przy okazji – warto zwrócić uwagę na sztuczki zastosowane po to, by uniknąć sytuacji, w której dwa różne PIN szyfrują się do tej samej wartości (wykorzystany jest 3DES w trybie ECB).
Oryginał tego wpisu dostępny jest pod adresem Dlaczego szyfrowanie jest (czasem) lepsze
Autor: Paweł Goleń
Wczoraj miałem okazję być na warsztacie/prezentacji Bezpieczeństwo danych w szwajcarskim banku – proces analizy ryzyka IT w UBS, który odbył się w ramach BAIT. Muszę przyznać, że wyszło to całkiem dobrze, Marcin dał radę w ciekawy sposób opowiedział o co w tym wszystkim chodzi. Ja się tam prawie nie odzywałem :)
Oczywiście trzeba pamiętać, że temat jest bardzo rozległy i w takim czasie nie można opowiedzieć o wszystkim. Podstawowe rzeczy jednak zostały poruszone. Podstawowe, czyli:
Jest też mały konkurs ;)
P.S. Tak na marginesie – ciekawe jest na przykład to, że taki podstawowy termin jak ryzyko wcale nie jest jednoznacznie zdefiniowane. Dwie osoby o różnym “pochodzeniu” (background zawodowy) używając pojęcia ryzyko mogą w rzeczywistości mówić o dwóch zupełnie innych rzeczach.
Oryginał tego wpisu dostępny jest pod adresem Warsztaty BAIT
Autor: Paweł Goleń
Dziś cofnijmy się mniej więcej o rok, konkretnie do tego wpisu: Jak zepsuć uwierzytelnienie w aplikacji mobilnej? A konkretnie do tego przypadku, w którym hasło (PIN) do aplikacji mobilnej było wykorzystywane do wygenerowania klucza używanego do szyfrowania danych przechowywanych lokalnie na urządzeniu. W opisywanym scenariuszu skutki takiego rozwiązania były tragiczne – kwestią sekund było odzyskanie kodu PIN potrzebnego do uwierzytelnienia się w aplikacji, oczywiście pod warunkiem, że ktoś wcześniej uzyskał dostęp do urządzenia ofiary.
Tym razem pokażę w jaki sposób zmodyfikować to rozwiązanie, by było odrobinę lepsze.
Dzisiaj komentarz do tego tematu: Okradli klientów PKO BP, przez internet, bez znajomości kodów jednorazowych. Właściwie do pewnego stopnia mój komentarz jest tutaj, ale tematowi warto poświęcić kilka słów więcej.
Zachęcam do posłuchania Risky Business #305 — Secure, anonymous IM not a pipe dream. Konkretnie chodzi mi o rozmowę dotyczącą bezpiecznego IM.
W czym jest problem, czy szyfrowanie nie wystarczy? Okazuje się, że bardzo często – nie. Trzeba pamiętać, że komunikacja ma wiele “cech”:
Warto również zwrócić uwagę na to, że zmiana typowych wzorców komunikacji również sama w sobie jest informacją.
Szyfrowanie w miarę skutecznie ukrywa tylko ten ostatni element. Na podstawie pozostałych cech nadal można wyciągnąć bardzo interesujące wnioski. Zwłaszcza, jeśli są jakieś dodatkowe dane, które można korelować. Można przypomnieć tutaj choćby przykład z “odgadywaniem” na co ktoś patrzy w Google Maps: I can still see your actions on Google Maps over SSL. To wszystko powoduje, że Pidgin z OTR nie zawsze wystarczy.
P.S. I w ramach ciekawostki: Operacja Fortitude.
(...) Utworzono grupę radiostacji które “porozumiewały” się wzajemnie nadając komunikaty o treści, jakich można się spodziewać w czasie formowania dużej grupy armii. (...)
Oryginał tego wpisu dostępny jest pod adresem Do posłuchania: Risky Business #305
Autor: Paweł Goleń
Zdecydowanie warto przeczytać: The Security Impact of HTTP Caching Headers. Temat nie jest nowy, jednak wciąż sytuacja w tym zakresie wygląda słabo. Bardzo często można natknąć się na dwie skrajne sytuacje:
Obie skrajności są złe, w pierwszym przypadku pojawia się problem z poufnością informacji. Treść, która w teorii powinna być dostępna tylko dla konkretnego użytkownika, może zostać zapisana w wielu, bliżej nieokreślonych miejscach. Drugi scenariusz z kolei jest uciążliwy pod względem wykorzystania zasobów – wielokrotne pobieranie tych samych treści kosztuje nie tylko przepustowość, ale również czas.
Dla zwykłego użytkownika sam fakt wielokrotnego pobrania tych samych danych może być nieistotny. Istotny za to będzie wydłużony czas ładowania strony – to coś, co taki zwykły użytkownik jest w stanie zauważyć.
Na koniec – przypominam, że jakiś czas temu przygotowałem stronę, na której z tymi nagłówkami można sobie poeksperymentować.
Oryginał tego wpisu dostępny jest pod adresem Do poczytania: The Security Impact of HTTP Caching Headers
Autor: Paweł Goleń
Do poczytania: A roster of TLS cipher suites weaknesses. Ciekawy zbiór aktualnych informacji odnośnie tego co obecnie w TLS jest, a co nie jest bezpieczne.
Oryginał tego wpisu dostępny jest pod adresem Do poczytania: A roster of TLS cipher suites weaknesses
Autor: Paweł Goleń
Tak jak zapowiadałem, byłem na kolejnej edycji Security B-Sides w Warszawie. Wrażenia? Mieszane.
Ostatnio wspominałem, że jeden z moich laptopów zachowuje się dziwnie. Podejrzewałem nawet jakiś problem sprzętowy. Być może udało mi się nawet go zidentyfikować – karta SD. Konkretnie karta, którą używałem do ReadyBoost. Po wyłączeniu tej funkcji system odzyskał stabilność.
Już kiedyś widziałem kartę, z której system odczytywał coś innego, niż na nią zapisywał. Nawet to nie była kwestia karty, tylko przejściówki. Jeśli znajdę czas, może przeprowadzę kilka testów czy takie zachowanie uda się zaobserwować i tym razem. Jedyne co mnie dziwi, to fakt, że ta karta w tej roli sprawowała się dobrze przez długi czas. Może za długi?
Oryginał tego wpisu dostępny jest pod adresem Czyżby TO było problemem sprzętowym?
Autor: Paweł Goleń