Zwykle o wycieku danych użytkowników dowiadujemy się wtedy, gdy ktoś się ich posiadaniem pochwali. Nie musi to oznaczać, że ofiara (źródło wycieku) nie wie, że taka sytuacja miała miejsce. Po prostu wolą nie przyznawać się do takiej wpadki, a jeśli już muszą, to podają jak najmniej szczegółów, lub używają popularnego ostatnio słowa klucza: APT. Takie postępowanie można nawet zrozumieć patrząc na często irracjonalne zachowania ludzi, nie koniecznie związane IT (np. lęk przed lataniem po głośnej katastrofie lotniczej, nawet jeśli rozbił się zupełnie inny typ samolotu z jakichś szczególnych powodów). Po prostu percepcja ryzyka u ludzi mocno rozmija się z tym, jakie to ryzyko rzeczywiście jest. Ale ja chciałem o czym innym...
Mówić, nie mówić?
W ostatnim czasie był jeden ciekawy przykład, w którym prawdopodobna ofiara poinformowała swoich użytkowników, że być może miał miejsce incydent bezpieczeństwa, w trakcie którego być może wypłynęły hashe haseł i atakujący być może będą w stanie ustalić hasła tych użytkowników, którzy korzystali z prostych haseł. Tak, chodzi mi o LastPass. Warto zapoznać się z tym wpisem na ich blogu: LastPass Security Notification, a szczególnie z ostatnią aktualizacją z 16 maja i tym fragmentem, w którym piszą o błędach jakie ich zdaniem popełnili w trakcie informowania o incydencie i "sprzątania" po nim. Warto się zapoznać z całą historią i wyciągnąć wnioski dla siebie.
Nieinformowanie użytkowników o incydencie jest złe, ale informowanie o nim czasami również może spowodować nieoczekiwane efekty. W tym wypadku użytkownicy rzucili się do zmiany haseł, nawet jeśli używane przez nich hasło było na tyle mocne, że ta zmiana nie była wymagana (trochę myśli na ten temat całej sytuacji pisałem tutaj: Najpierw miało być o LastPass, a potem mnie poniosło). Ich infrastruktura nie była przygotowana na tak duże obciążenie, w związku z czym usługa przez pewien czas prawie nie działała (w praktyce - prawie jak DDoS). Dodatkowo do obsługi zdarzenia próbowano wykorzystać funkcje, które nie były do końca gotowe (np. brak wystarczającej bazy danych o wcześniejszych logowaniach) lub takie, do których nie byli przyzwyczajeni użytkownicy (logowanie offline). Jakby tego było mało, to jeszcze platforma blogowa, którą wykorzystywali do komunikacji ze swoimi użytkownikami, przez pewien czas była niedostępna...
Bezpieczeństwo to nie tylko zabezpieczenia. One najczęściej po prostu "kupują czas". Potrzebna jest jeszcze detekcja oraz reakcja. W przypadku haseł przechowywanie ich w formie hashy kupuje czas. Ile tego czasu? To zależy od tego, jakie hashe są wykorzystane (patrz How To Safely Store A Password, choć sam wiele razy na ten temat w podobnym tonie pisałem: Coś mocniejszego niż MD5, Nudy: znowu o przechowywaniu haseł), a także od hasła wybranego przez użytkownika. Korzystając z tego czasu użytkownik może zmienić feralne hasło wszędzie tam, gdzie je użył (w przypadku LastPass miało to jeszcze większe znaczenie). Oczywiście użytkownik prawdopodobnie zmieni swoje hasło doiero wtedy, gdy się dowie, że powinien to zrobić. Dowie się, jeśli firma (ofiara, źródło wycieku) go o tym poinformuje, a nie poinformuje go na pewno, jeśli sama się nie dowie, że hashe haseł jej wyciekły. Widać tu wyraźnie wszystkie trzy elementy:
- zabezpieczenie - przechowywanie hashy haseł w poprawny sposób,
- detekcja - możliwość wykrycia incydentu (prawdopodobnego wycieku),
- reakcja - usunięcie podatności umożliwiającej wyciek, poinformowanie użytkowników o zdarzeniu, inne działania "sprzątające",
W przypadku LastPass zabezpieczenie było, choć nie do końca poprawne, w związku z czym słabsze hasła były narażone bardziej, niż powinny. Detekcja w pewnym stopniu zadziałała, została wykryta jakaś anomalia, była ona na tyle niepokojąca, że zdecydowano o poinformowaniu użytkowników o tym zdarzeniu, nawet mimo braku pewności, że rzeczywiście doszło do wycieku hashy haseł użytkowników. Upublicznienie informacji o zdarzeniu było częścią reakcji.
Teraz można się zastanawiać, czy podjęte działania były słuszne. Nie, nie po to, by pastwić się nad LastPass i wytykać ewentualne błędy. Sytuacje wyjątkowe mają to do siebie, że są... (a to niespodzianka) wyjątkowe. Warto popatrzeć jak inni sobie radzą w takich sytuacjach i wyciągać wnioski dla siebie. Wszystko po to, by uniknąć ich błędów i jednocześnie wykorzystać to, co było dobre. A w zakresie reakcji i informowania użytkowników/klientów o zdarzeniu oraz potencjalnych skutkach, jakie to zdarzenie może mieć dla nich jest jeszcze wiele do zrobienia.
Oczywiście masz rację, że jeśli jednak wyciekły bloby, to sama zmiana hasła nic nie da (http://niebezpiecznik.pl/post/atak-na-lastpass/#comment-34236). Jeśli natomiast hasło było silne, to prawdopodobieństwo odszyfrowania składowanych blobów (w sensownym czasie), jest niskie.
Swoją drogą właśnie takie sytuacje pokazują, że okresowa zmiana hasła jednak ma sens. Ja korzystając z KeePass przypisuje swoim hasłom roczny okres ważności. Dzięki temu nawet jeśli z jakiegoś serwisu moje hasło wycieknie, to atakujący mają z góry ograniczony czas kiedy muszą złamać hasło by mieć z tego jakikolwiek pożytek.
swoją drogą - odpowiedź Tomka na przytaczany przez Ciebie komentarz do wpisu na niebezpieczniku trochę martwi... "przechowywałem w swoim kontenerze tylko silne hasła - nie muszę ich zmieniać"